![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
I didn't mention this bug when I discovered it on Friday:
Resetting statistics for a ProfileSet is a time-consuming operation. The changes Nick and I made last summer helped a lot, but there's still still significant I/O of opening and closing databases, and I/O is slow. Resetting statistics consumes at least a few seconds.
On Friday, I discovered that the annotation engine code was resetting statistics every time it created a filter, instead of doing it only once--and an analysis tree will have a few dozen filters.
Today, I started the day by changing that code to reset statistics lazily, so it resets only once. It should speed up the loading phase dramatically.
Resetting statistics for a ProfileSet is a time-consuming operation. The changes Nick and I made last summer helped a lot, but there's still still significant I/O of opening and closing databases, and I/O is slow. Resetting statistics consumes at least a few seconds.
On Friday, I discovered that the annotation engine code was resetting statistics every time it created a filter, instead of doing it only once--and an analysis tree will have a few dozen filters.
Today, I started the day by changing that code to reset statistics lazily, so it resets only once. It should speed up the loading phase dramatically.
no subject
Date: 2001-09-24 11:21 am (UTC)no subject
Date: 2001-09-24 11:41 am (UTC)It really comes down to questions of bandwidth versus latency--we would lik eto be in a better world where stuff wasn't so badly wrong, but right now we're trying to get stuff ready in hopes of making sales, so we keep patching instead of taking the to time to do things right and well--even when that would save us time and pain in the long run.
This is also why we're not using DPFMT.
no subject
Date: 2001-09-24 12:28 pm (UTC)There was no easy way at the time to figure out when the class's user was done adding filters so that we could do statistics resetting then. (At least we were doing the 20-second version of statistics-reset rather than the 5-minute version (: )
Upon reflection, changing the half-wrapping we had around the profileset to a full wrapping and catching the first run invocation could have done it. You probably did something similar?
no subject
Date: 2001-09-24 12:53 pm (UTC)ResetStats just records that the stats need to be reset, and they actually get reset before RouteDocument.
(I actually kept the awkward half-wrapping structure, but I added a sibling to GetProfileSet() called EnsureValidProfileSet() that reset the statistics if necessary before handing back the profile set. I use EnsureValidProfileSet() in the two places where I need it, and it works. But if I had the time, a more complete wrapper might be better.)