Ed Leafe wrote: > On Dec 23, 2006, at 10:51 AM, Paul McNett wrote: > >>> from dabo.lib.profilehooks import process as profile >>> >>> @profile >>> def requery() >> Any idea which package I need to install to get profile? I swear in >> prior ubuntu's I had it without having to do anything special. >> >> File "/home/pmcnett/projects/dabo/dabo/lib/profilehooks.py", line >> 105, in ? >> from profile import Profile >> ImportError: No module named profile > > That's a Python standard module - you shouldn't have to install > anything.
I'll dig some more when I get a few minutes. >>> First verify where the slowness is. >> Well, I verified it by noting how many records were being iterated >> over, >> and how long each iteration takes. No doubt we could speed up the >> iteration in various places, but do you have any problems with >> inverting >> the design like I suggested, since I believe that will be much more >> scalable? > > I always like to make sure that I know just what the problem is > before determining what the best solution is. Profiling has usually > verified my hunches, but has also revealed that the main bottleneck > was not exactly what I had assumed. Definitely. Like when I figured out that the whole init cycle for dPemMixin-objects was running twice. :) > The only problem with those designs would be ensuring that if a > value is changed and then changed back to the original, that it > recognizes that it hasn't changed. VFP has really stupid buffers; > code such as 'REPLACE myField WITH myField', which doesn't change > anything, results in a dirty buffer. That's one of the reasons I > wrote the Memento class for Codebook, and implemented it in Dabo, too. I like the memento, and am not suggesting removing it. However, it strikes me that: + We only need a memento from the moment a field value is modified. Currently, we copy the mementos for each record after every requery, which is another potential O(N) slowdown. + If we had a Mementos structure, keyed on the row number, and we only added a memento for a record when there was a field change made, to find out if there are any changes we only need to query len(cursor.mementos). + Additionally, processes like saveAll() that currently iterate all rows would only need to iterate the rows that are in cursor.mementos. > > Here's an example that you need to make sure is handled correctly: > > Orig: > field1 = 100 > field2 = "paul" > > change field1 to 200 > => isChanged = True > change field2 to "ed" > => isChanged = True > change field1 back to 100 > => isChanged = True > change field2 back to "paul" > => isChanged = False I believe my cursor.mementos structure would satisfy this requirement with nothing special. General encouragement for trying to implement something along these lines? -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
