This confirms the 2.5x speedup of trunk vs stable. It will take me some time to go over the other patches but I will. Thanks Alexey.
Massimo On Jun 9, 6:10 am, Alexey Nezhdanov <[email protected]> wrote: > Results of second set of test runs: > > r875 45.523ms > r882 20.614ms > inits v.1 18.464ms > inits v.2 18.677ms > inits1+lazyT 15.377ms > inits2+lazyT 15.280ms > > Observed noise was 0.502ms for slowest execution (90:1 > signal-to-noise) and 0.889ms for fastest execution (16:1 > signal-to-noise). > Given than, I think it is safe enough to say that > "this particular application on this particular hardware/OS > combination was sped up 2.88...3.31 times". > > As in last case - for completeness I'm attaching full console output > > I think I know what I'll do. Currently I do not want to release my > project as any kind of open-source. But I can > 1) Strip out any code I do not use in this perfomance testing > 2) rename all sensitive fieldnames/variables to something like field1, > field2, var3, var4. > Release resulting package. It would be useless as it is, but it will > have same perfomance parameters so could be used for testing. > > On Tue, Jun 9, 2009 at 1:35 PM, Alexey Nezhdanov<[email protected]> wrote: > > Wrote 'optimised inits v2' patch. Tested everything. > > > Once again I changed my testing pattern a bit. > > > 1) I dumped my own timing tool in favor of much more standard > > 'ab' (apache benchmark). > > > 2) I decidedly will publish all these results in two main. > > I just finished first round of testing. Here are results (reported > > values are average request time in milliseconds. If anyone interested > > - I'm attaching a full output from my console). > > I will do all that testing again and publish same results again so > > that the amount of noise in all this will be public and clearly > > visible (here I'm fighting with my own temptation to rerun the tests > > if timings seem to be 'too away' to me). > > > First four lines share my app's db.py. Last two require a modified > > db.py, but modification is cosmetical - each define_table is put into > > separate function and I do db.tablename=create_table_tablename after > > each function. Model init time was not measured. > > > No more words. Dry figures only. Each line represents result of 10k > > requests. > > r875 46.025ms > > r882 21.048ms > > inits v.1 18.918ms > > inits v.2 18.122ms > > inits1+lazyT 16.032ms > > inits2+lazyT 14.391ms > > > P.S. I'm surprised about last line... Noise? > > > On Tue, Jun 9, 2009 at 11:12 AM, Alexey Nezhdanov<[email protected]> wrote: > >> new testing: > > >> ---- SERVER KERNEL ---- > >> --prints > >> r875 0.04898 > >> r822ini 0.03070 1.60x > >> --silent > >> r875 0.04914 > >> r822ini 0.03049 1.61x > > >> So I get much more consistent results on this hardware. > >> While this is obviously not the best perfomance (my weaker box, > >> with less RAM, troubled with video output 1280x1024, > >> software 90deg rotation - performs BETTER), that does not matter. > >> What does - is that I can now be sure that these results are > >> noise-free so I can safely compare timings from various patches. > >> Proceeding with writing 'inits v2'. > > >> On Tue, Jun 9, 2009 at 10:43 AM, Alexey Nezhdanov<[email protected]> wrote: > >>> Ok. Now the confusion is resolved. > >>> 1) Speed improvements of 70% and up that I reported yesterday are > >>> really exist. I just reproduced a 3.47 times model speedup and 2.15 > >>> overall speedup for my app (r875 vs r822+inits). > >>> BUT this app is atypical. I have added some time measuring code there > >>> so it prints out two lines per each model init. So when I am testing > >>> perfomance - screen very quickly scrolls up > > >>> 2) Simply commenting out two print statements gives me only 1.67 > >>> overall speedup given equal other conditions. I think that processor > >>> receive additional interrupts from videocard that in turn results in > >>> more often checks of tasks queue. > > >>> 3) I declare all my previous testing results spoiled by noise > >>> generated by print statement and inappropriate kernel scheduler > >>> setting. > >>> I've set up yet another test box with these parameters: > > >>> Intel Core2 Duo 2.66GHz, 2G RAM, Ubuntu 9.04, 'server' flavour kernel > >>> 2.6.28-11.42. Initially I considered to install a 'realtime' kernel, > >>> but it appeared to be unstable on that hardware (and afterall - it's > >>> for sound/video processing and 'server' type is more likely to be > >>> installed on servers). > > >>> Will report new testing results (and finally I hope to write > >>> 'optimised inits ver.2' patch) later today. > > >>> On Tue, Jun 9, 2009 at 5:14 AM, mdipierro<[email protected]> wrote: > > >>>> Please try launchpad 893. I think it should be faster on GAE. > >>>> We can do better with lazy tables but at least the validators and > >>>> calls to getitem are eliminated. > > >>>> Massimo > > >>>> On Jun 8, 1:05 pm, Markus Gritsch <[email protected]> wrote: > >>>>> On Mon, Jun 8, 2009 at 5:54 PM, mdipierro<[email protected]> > >>>>> wrote: > > >>>>> > the web2py in trunk can execute models 2.5x faster than the current > >>>>> > stable/production version (requires migrate=False and bytecode > >>>>> > compiled models). > > >>>>> Will this speedup also has an effect on GAE? IMO one uploads no .pyc > >>>>> files? > > >>>>> Markus > > > > ab-runs2.gz > 1KViewDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
