|Subject:||Re: Added support for file list in single file update|
|Date:||Thu, 26 Jun 2014 11:31:42 +0900|
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
I can by using '+'. I use '+' for added/modified files.
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()?
> I guess that most everyday updating are change.
> If so, it means that you cannot reduce stat() greatly.
The remote box is a NAS storage appliance (NetApp - I work there) and
> 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?
cannot run GNU tools without significant porting efforts.
>> Modified batch operation without prefix:
>> $ time gtags --single-update no-prefix.files
>> real 0m7.145s
>> user 0m1.438s
>> sys 0m1.229s
>> Modified batch with prefix:
>> $ 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
[PS: I am not sharing the actual file names to avoid sharing any company data]
Sure, once I untangle the mess I have created locally :-)
>> 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.
with best regards,
|[Prev in Thread]||Current Thread||[Next in Thread]|