Alexey, I am lost with all the attachments. If there is something you want me to include please send me by email one patch that applies to the lastest trunk. I would not yet include lazy table evals just yet since I need to think more about it. I think there may be an easier way of doing but since I am rewriting the DAL anyway I think it is best to wait.
Massimo On Jun 10, 7:48 am, Alexey Nezhdanov <[email protected]> wrote: > On Wednesday 10 June 2009 16:31:31 AchipA wrote:> > > > So on my laptop > try:except: function loses about 5% to regex - > > > > > probably it depends on hardware/OS. > > > > > Interesting, which python/platform are you using ? > > > > Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) > > > [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 > > > Hm, is it perhaps 32bit ? That could be related to int performance... > > Yes. 64-bit OS was too buggy so after several attempts I gave up and continued > using 32bit. > > > > > > > b...@black:/tmp$ python -m timeit "s=[str(i) for i in range(10000)]" > > > > "import re" "integer_pat=re.compile('[+-]?[0-9]{1,15}$')" > > > > "is_integer=integer_pat.match" > > > > 100 loops, best of 3: 3.64 msec per loop > > > > Hmm? No loop... > > > Timeit loops, it is looping over your code. So, the above means timeit > > ran the code 100 times. > > > > I'm sorry, how do you get 6.2x? > > > 9.87/ 4.63 =2.13 here... > > > Subtract the init (3.6msec) time from both. just wanted to avoid the > > extra cost of the import. However, even when doing it 'more right' I'm > > getting a significantly larger number (although unlike my firrst > > example this does not take into account the varying length of > > strings). > > I see. I'm not sure if we are allowed to do that (substraction) though. > > > blinky:~# python -m timeit -s "import re" -s "integer_pat=re.compile > > ('[0-9]+$')" -s "is_integer=integer_pat.match" "is_integer('123')" > > 1000000 loops, best of 3: 0.574 usec per loop > > blinky:~# python -m timeit "'123'.isdigit()" > > 10000000 loops, best of 3: 0.141 usec per loop > > > The problem of your methodology (timing a total run) is that you're > > averaging out results and polluting the results with load noise from > > the OS and other apps. Timeit (among other neat tricks) counts the > > timing of the *BEST* iterations. If one was slower than the other, > > that means that the other got interrupted somewhere (disk, app, > > multitaskting, etc). > > > Seehttp://docs.python.org/library/timeit.html, it's quite useful. > > I was wondering during my previous testing if I should use only 'minimal' > time. Thank you for the link, will read. > > -- > Sincerely yours > Alexey Nezhdanov --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
