Oy Vey

Sep. 24th, 2001 01:23 pm
ralphmelton: (Default)
[personal profile] ralphmelton
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.

Date: 2001-09-24 11:21 am (UTC)
cellio: (Default)
From: [personal profile] cellio
Have you folks actually done the cost-benefit analysis on fixing vs rewriting this code?

Date: 2001-09-24 11:41 am (UTC)
From: [identity profile] ralphmelton.livejournal.com
We have not done so in any formal way.

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.

Date: 2001-09-24 12:28 pm (UTC)
From: [identity profile] dvarin.livejournal.com
So, um, we did that deliberately.
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?

Date: 2001-09-24 12:53 pm (UTC)
From: [identity profile] ralphmelton.livejournal.com
I did something similar to what you described, yes.

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.)

Profile

ralphmelton: (Default)
ralphmelton

April 2018

S M T W T F S
1234567
891011121314
151617181920 21
22232425262728
2930     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 26th, 2025 03:11 am
Powered by Dreamwidth Studios