Thanks Alexey, since these tests are on a different architecture, can you give the total relative speedup on the same architecture for executing your original model (code in trunk vs original code)?
Massimo On Jun 8, 5:49 am, Alexey Nezhdanov <[email protected]> wrote: > Hi again. > Here are another testing results. > > First of all, let me remind you about is_integer bug. It doesn't allow > negative numbers. Correct code is: > is_integer=re.compile('-?[\d]+).match This is not a bug. Since ID values cannot be negative. > Now. I've run more timings, more profiling and more code tweaks. > This time it was Core2 Duo @2.20GHz with 1G RAM. Ubuntu 8.04. > Testing strategy: 20 sets of 1000 GET requests to the main page. Same > application as before. For each set I have average GET request time. > For a group of 20 sets I get minimum average, global average and > maximum average. Also I have average model init time for 20k requests > (no splitting into each set). > > 1) Upstream sql.py > model 0.01646 > min 0.02979 > avg 0.03267 > max 0.03597 > > 2) Optimised SQLTable.__init__ and SQLField.__init__ (patches > attached, backwards compartible, though you may want to remove my > testing marks) > model 0.01380 > min 0.02697 > avg 0.03003 > max 0.03189 > So - about 8% speedup (by avg time) here. > > 3) Now lazy tables (patch attached). > Since I expect that you will not find any objections to my patches for > (2) here are cumulative results, i.e. optimised __init__s + lazy > tables > ... > hmmm. It doesn't improves results significantly anymore. It looks like > these patches are interchangeable. I've run my test three times, > results are: > > model 0.01009 > min 0.02555 > avg 0.0297105 > max 0.033360 > > model 0.01012 > min 0.02369 > avg 0.02983 > max 0.03340 > > model 0.00966 > min 0.02415 > avg 0.02850 > max 0.03208 > > So it makes some improvement about 1%-5% but somehow it also makes > testing results more disperse. Do not know if it worths including. > Massimo, your opinion? > > 4) Also I've tried to further speedup validator generation w/o losing > backwards compartibility, but improvement was about 1% and below the > margin of error (even less noticeable than with lazy tables). > > On Sun, Jun 7, 2009 at 11:45 PM, Alexey Nezhdanov<[email protected]> wrote: > > On Sunday 07 June 2009 18:41:30 mdipierro wrote: > >> I implemented a backward compatible speedup of the default validators. > >> I also realized that those many calls to is_integer could be avoided. > >> I think I fixed it. > > 0.0429/0.0844 > > Somehow consistency is not kept across reboots :( > > ... about a hour later: and actually now I get about 10% noise so it become > > very hard to make any good measurements. I'll try tomorrow on better > > hardware. In the meanwhile, I'll try to profile it once again. > > ... > > ok, there are still two perfomance hogs left: SQLTable.__init__ (about 11%) > > and SQLField.__init__ (about 6,5%). These percentages are 'self' times - > > i.e. > > it was spent directly in lines 1099-1149, 1693-1752. > > Python profiling doesn't allow to attribute CPU consumption to individual > > lines so for now I don't have any more precise pointers. But that could be > > split into functional blocks and narrowed further down. > > > In any case - we collected almost all low-hanging fruits. Any further > > optimisation will give gains of range 2-5%, not times anymore. > > > Except lazy tables which still may give tens of percents. BTW - Massimo, you > > said something about SQLLazyTable class. You should implement SQLLazyField > > too then. Or may be just wait a day or two until I do deeper profiling. > > >> Please check out the latest trunk. > > >> Massimo > > > P.S. Here is small fix to is_integer. We forgot about negative numbers: > > Also this version is tiny bit faster > > is_integer=re.compile('-?[\d]+).match > > > -- > > Sincerely yours > > Alexey Nezhdanov > > > > x_table.diff > 6KViewDownload > > x_field.diff > 2KViewDownload > > lazy_define_table2.diff > 2KViewDownload --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
