microsoft / microsoft/vscode-cpptools

Tag parser is very slow on a C++ file with an include that contains a symbolic link

Open
#10,247 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Language Service parser performance symlinks
Dominant language
TypeScript
Stars
6.2k
Forks
1.7k
Avg merge
14h 46m
Merged PRs (30d)
61

Description

Environment
  • OS and Version: Windows, 10
  • VS Code Version: 1.74.0
  • C/C++ Extension Version: 1.13.6
  • Other extensions you installed (and if the issue persists after disabling them): CMake, CMake Tools, Doxygen Documentation Generator, Perforce for VS Code
  • If using SSH remote, specify OS of remote machine: Using SSH remote, connecting to RHEL Linux 7.6
  • A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).: Our workspace seems to get parsed fine until it hits a Qt MOC'ed file. This generates a file with a #include that looks something like: #include "../../../../../src/my_dir/my_cpp_file.h". In this case, ../../../../../src is a symbolic link pointing to /home/AUser/dev/src. When I replace the ../../../../../src with /home/AUser/dev/src, the tag parser blazes through the file and doesn't get stuck.
    After waiting for about 5 minutes, it finally proceeded to finish parsing the file, which is only about 100 lines.
Bug Summary and Steps to Reproduce

Bug Summary:

The tag-parser seems to seriously degrade in performance on an include that has a symbolic link in the path. For example, Qt's moc produces moc_<source_Name>.cpp files where the first #include looks something like #include "../../../../../src/my_dir/my_cpp_file.h". In this case, ../../../../../src is a symbolic link to /home/AUser/dev/src.

When I replace the ../../../../../src with /home/AUser/dev/src the tag parser takes less than 1 second. With the symbolic link, it takes about 5 minutes to tag-parse the file.

I tried to replicate this with a small, reproducable project, but I was unable to. The project is somewhat large that I am working on (~11000 files). Essentially, Qt's MOC executable produces a moc source file that has the following includes:

#include <memory>
#include "../../../../../src/my_dir/myFile.h"
#include <QtCore/qbytearray.h>
#include <QtCore/qmetatype.h>
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file myFile.h' doesn't include <QObject>."
#elif Q_MOC_OUTPUT_REVISION != 67
#error "This file was generated using the moc from 5.15.10. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endif

As explained above, the src in the path is a symbolic link and the tag parser seems to fail on that include. Like I said before, if I manually modify that include to use the real path to the file, the tag parser continues.

Expected behavior

Include paths with symbolic links shouldn't degrade performance that bad.

Code sample and Logs
As this is a company project, I cannot post the output from the Log, as it contains many paths to our private source code.
Screenshots

No response

Additional context

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the slowdown with a Qt-generated C++ moc file whose include path contains a symbolic link, comparing it with the equivalent real path. Investigate the tag parser's handling of that include and use the reported timing difference as the completion check.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
performance, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.