[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Added support for file list in single file update

From: dhruva
Subject: Re: Added support for file list in single file update
Date: Wed, 25 Jun 2014 18:12:36 -0700

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'?



[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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]