Re: Entries caching & Performance

[Kevin Pilch-Bisson <ke...@pilch-bisson.net>]

On Mon, Nov 25, 2002 at 11:57:09PM +0000, Philip Martin wrote:
> That's not correct, entries are cached for all operations.  At present
> operations that modify the working copy will repeatedly *write* the
> entries file, but it does not get read repeatedly.  Writing happens
> repeatedly because a) that's how it worked originally, and b) if it
> didn't then an interrupted operation would lose all its modifications.
> (I know interrupted checkouts cannot be restarted, but that's a bug
> that needs to be fixed.)

I took a quick look at this, and the update editor for checkouts is created
with a null adm_access.  Maybe it is created and used later, but I didn't see
it.
> 
> Obviously every relevant entries file has to be parsed once.  Are you
> seeing the same file parsed repeatedly?  How many times does
> svn_wc_entries_read go on to call read_entries?
> 
> > implementing cached entries readings for updates & checkouts? This
> > could possibly eliminate a large portion of the time spent during
> > updates.
> > 
> > The other half of the time spent comes from ne_xml_parse.  I am not
> > sure how this could be made faster short of replacing expat with
> > something faster.
> 
> Is there such a thing?  I don't know whether expat is fast or slow,
> but simply asking for it to be replaced with something faster isn't
> much help unless you can identify something that is faster :)
> 
I don't think there is much we can do here.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Entries caching & Performance

[Philip Martin <ph...@codematters.co.uk>]

Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:

> On Mon, Nov 25, 2002 at 11:57:09PM +0000, Philip Martin wrote:
> > That's not correct, entries are cached for all operations.  At present
> > operations that modify the working copy will repeatedly *write* the
> > entries file, but it does not get read repeatedly.  Writing happens
> > repeatedly because a) that's how it worked originally, and b) if it
> > didn't then an interrupted operation would lose all its modifications.
> > (I know interrupted checkouts cannot be restarted, but that's a bug
> > that needs to be fixed.)
> 
> I took a quick look at this, and the update editor for checkouts is created
> with a null adm_access.

Tricky to do otherwise for a checkout...

>  Maybe it is created and used later, but I didn't see
> it.

The update editor caches the access batons within the editor. At
present there is no simple way to return those to the caller (see
close_edit), so if the caller wants to do something else, such as
storing auth info, it needs to open them again.

I have remembered that entries files may be read twice for some
operations.  There are two sets of entries, one without deleted items
(not items scheduled for deletion, but items in state deleted) and one
without.  The caching code creates which ever set the read code asks
for, but if the one with deleted items is available it uses that to
create the one without, and thus avoids parsing the file.  So if an
operation requires both sets, but asks for the set without deleted
items first, then the file will get parsed twice.  It's a memory/speed
tradeoff.  If we always created the entries set with deleted items
even if the read code asks for the set without, we would not sometimes
parse the file twice, but we would sometimes use more memory.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org