xulion / scope4code

cscope support for visual studio code
MIT License
21 stars 8 forks source link

performance issue #48

Closed ymartineau closed 4 years ago

ymartineau commented 4 years ago

hi,

I tried to find all symbols on a variable in a large c++ project (cscope.out ~900MB) where scope4code is supposedly more relevant than the standard vscode indexer and it took approximately 1 minute and 30 seconds while it took approximately 4 or 5 seconds in vim or with the standalone cscope. There were about 10 or 15 references returned by cscope, so I don't understand why it took so long for vscode or scope4code to display those results. Unfortunately I don't have the time to investigate the performance issue yet but I'm just curious to understand what could explain this delay.

Anyway, thanks for sharing this tool.

BR

yohann

xulion commented 4 years ago

Yohann,

Sorry for late reply. The performance shall be pretty much the same. Do you mind check if you are using the same command line parameter you are using with vi?

Default setting (cscope -q -k) would let cscope to rebuild database every time when there is code change. You can change the setting to "cscope -q -d -k" and try (with -d you have to manually rebuild database after code change).

ymartineau commented 4 years ago

hi,

thank you for your answer, I managed to update settings. For the moment, I'm mainly browsing code, so I didn't change the build database command but only the find* commands so that database is not rebuilt each time a find* command is invoked (just added the -d option).

Here is my settings.json:

{
    "scope4code.engineCommands" : {
        "config_index" : {
            "cscope" : {
                "win32" : 1,
                "linux" : 0
            }
        },
        "config" : [
            {
                "find_cmd" : "find ${src_path} -type f -name *.c -o -type f -name *.h -o -type f -name *.cpp -o -type f -name *.cc -o -type f -name *.mm",
                "database_cmd" : "cscope -b -q -k",
                "find_all_ref" : "cscope -d -q -k -L0 ${text}",
                "find_define" : "cscope -d -q -k -L1 ${text}",
                "find_callee" : "cscope -d -q -k -L2 ${text}",
                "find_caller" : "cscope -d -q -k -L3 ${text}",
                "find_text" : "cscope -d q -k -L4 ${text}"
            },
            {
                "find_cmd" : "cmd /C dir /s/a/b ${src_path}\\*.c ${src_path}\\*.h ${src_path}\\*.cpp ${src_path}\\*.cc ${src_path}\\*.mm",
                "database_cmd" : "cscope -b -q -k",
                "find_all_ref" : "cscope -d -q -k -L0 ${text}",
                "find_define" : "cscope -d -q -k -L1 ${text}",
                "find_callee" : "cscope -d -q -k -L2 ${text}",
                "find_caller" : "cscope -d -q -k -L3 ${text}",
                "find_text" : "cscope -d -q -k -L4 ${text}"
            }
        ]
    },
    "scope4code.printCmdBeforeExecute": true
}

the output is still a bit long because the location of my project is quite deep in file system, but it is another concern. I guess it is due to the way the database is built (it might include full path name instead of relative path name).

Anyway, it becomes usable for me this way. Thanks a lot!

xulion commented 4 years ago

Yes, it's true it is using full path. I will try figure out if there is a way to use relative path (at least for the display).

PS. you don't have to configure command for both Linux and windows. config is an array and you can use config_index to tell which config the platform is using.