On Sat, Sep 12, 2009 at 03:15, Stefan Kueng <tortoisesvn_at_gmail.com> wrote:
> On 12.09.2009 03:18, Greg Stein wrote:
>>
>> As stsp notes, this is an artifact of continuing to use multiple sqlite
>> databases. Shoot ... we still haven't integrated the multiple property
>> files into the databases. That represents a *TON* more I/O then our
>> target implementation.
>
> I'm aware that the whole feature isn't finished yet. But I'm really worried
> that this can't be improved (speed wise) much even after all is finished.
> You said that it's because of using multiple sqlite dbs. But from what I saw
> with the ProcessMonitor during an update, only one or two sqlite files were
> accessed most of the time, especially the time where nothing seemed to
> happen and all CPU was used.
Yah. Bert identified that a while back in a tweak_entries() function.
When that massive delay first appeared, and Bert pointed to that
function, I took a look. What is happening in there can probably be
replaced by a SQL command or two, but it is doing *thousands* instead.
Your point is valid: we could have paused some of the general work,
and concentrated on fixing up that function with a spot change. I
decided not to focus on that, and solve some of the other, broader
problems instead. The delay at the end of an update is noticeable, but
it never passed my pain threshold. It seemed fine to wait and watch
that function evolve over time based on what we are doing to the
underlying layers. As it comes more into line with our new storage and
model system, then it should be easier to fix it the Right Way. That
just isn't very clear right now, beyond introducing some kind of
temporary hack.
And all that said, I do hear your worry. I think the only answer that
I can give is that I have faith that a move to a single database will
provide a *very* dramatic performance improvement. If it doesn't
happen, then I'll be right there with you, cursing the day that we
started this work :-P
>> Yes, you reported it a while back, and we were just as aware of it at
>> that time as now. This is a fuckton of work. If you want it sooner than
>> we are going, then jump in and help. I think you're underestimating the
>> work here, and the amount that has and is being done. Speaking for
>> myself, your comment makes my work feel unappreciated.
>
> I'm sorry, your work is definitely appreciated. And I'm sure the features it
> provides are great.
> But with the current performance, I would think that all those who are using
> trunk already would strive to improve the performance as soon as possible,
> to make it usable. Speaking for me, I tend to fix things that bother me in
> my work first. I assumed that you guys would feel the same, so I'm worried:
> either this performance is not really bothering you or there isn't much you
> can do about it? Either way, for me this doesn't look good.
Not bothering me enough to apply a temporary fix. At some point, an
obvious and proper fix will become apparent, but I haven't focused on
it, and it hasn't thrown itself out there yet. Given that Hyrum and
Bert haven't tackled it, I'd guess they're in about the same position.
I suspect we are all just waiting for a move to a single database
before looking at those performance choke points.
In short, the performance characteristics of the library *today* will
have zero relationship to the library we envision. Thus, any
performance work could be focused in entirely the wrong direction. I
hope that makes sense, and agrees with you.
>> The externals thing is an interesting point. Same will happen with
>> nested working copies that are not managed via externals. I think we may
>> want to handle those by default, but there are usability issues and some
>> backwards compat problems that could bite us. Could you please open an
>> issue with your ideas, so that I can track it to completion? Thanks.
>
> created issue #3483:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3483
Awesome. Thanks!!
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2393809
Received on 2009-09-12 09:39:06 CEST