Re: Added support for file list in single file update

[dhruva]

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 <address@hidden> 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