Off topic request: Have you considered moving to git version control?
It makes it easy to work on parallel topics. I have now created a mess
by adding the env for logical path, batch update and clean up calls to
test() by sending NULL for second call to test() with same path. I
have fixed test() to store a static pointer to path to allow repeat
call semantics to test("r") [which calls access() and that requires
the path].On Wed, Jun 25, 2014 at 5:43 PM, Shigio YAMAGUCHI <[email protected]> wrote: > Thank you for the data. > >> > It means that files with no prefix need stat()? >> >> Yes > > I guess that most everyday updating are change. > If so, it means that you cannot reduce stat() greatly. I can by using '+'. I use '+' for added/modified files. > First of all, if both source files and tag files are > in the remote file system, why don't you invoke gtags > in the remote host? The remote box is a NAS storage appliance (NetApp - I work there) and cannot run GNU tools without significant porting efforts. >> Modified batch operation without prefix: >> [1140]$ time gtags --single-update no-prefix.files >> >> real 0m7.145s >> user 0m1.438s >> sys 0m1.229s >> >> Modified batch with prefix: >> [1141]$ time gtags --single-update prefix.files >> >> real 0m7.081s >> user 0m1.496s >> sys 0m1.129s <-- reduction in time by avoiding stat (not >> significant though due to file system caching) >> >> => There is a visible benefit in batch processing of files > > I do not understand what you are testing. > Would you please show me the content of 'prefix.files' and > 'no-prefix.files'? prefix.files: +path/to/some/file1.cpp +path/to/some/file2.cpp +path/to/some/file3.cpp +path/to/some/file4.cpp non-prefix.files: path/to/some/file1.cpp path/to/some/file2.cpp path/to/some/file3.cpp path/to/some/file4.cpp [PS: I am not sharing the actual file names to avoid sharing any company data] >> Ran under valgrind and find 'strtol()' via calls to 'atoi()' as one of >> the biggest contributors to performance overheads. I am looking at >> storing the integer in DB and fetching it instead of storing the >> integer as char and having to convert it back to get fid. That will be >> a separate patch. Wish this was under git... (I will try to import it >> into git) > > This seems another issue. > Would you please post it separately. > Thank you in advance. Sure, once I untangle the mess I have created locally :-) with best regards, dhruva _______________________________________________ Bug-global mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-global
