Most of your patches are in but:
- is_integer: I am following Iceberg's suggestion
- skip_table_create: as proposed would have borken something so had to
move some code out of _create and in SQLTable.__init__. It i better
this way anyway
- no_dir_check: instead of removing it, I made it faster busing
hasattr and no more calls to dir
- validators, as proposed cannot be done. validators have customizable
error messages. they cannot be global, there must be one per field.
- lazy_define_table: I have not included this yet because it would be
more appropriate to implement a SQLTableLazy class. Before I do this I
would like to know how much speed-up we got already and what different
would the lazy tables do.
Thanks you Alexey. These were great patches and really made web2py
better.
Can you run your test again please and then we'll work on this more?
Massimo
On Jun 7, 5:35 am, Alexey Nezhdanov <snak...@gmail.com> wrote:
> On Sunday 07 June 2009 11:13:49 Alexey Nezhdanov wrote:> 1) When
> initialising, SQLField uses dir() call to find any clashes
> > with reserved names.
>
> I was a bit incorrect here. It checks for already defined fields too.
> Anyways - I optimised it by commenting it out :-P
> In practice I'd recommend similar approach:
> 1) don't check for clashes in the production environment (SQLDB init
> parameter?)
> 2) (optional) maintain cache of names for each table. Don't use dir().
>
> > 2) is_integer is a fast call, but with 1.1k (!) calls ...
>
> Replaced it with my own version:
> integer_pat=re.compile('[0-9]+$')
> is_integer=lambda x: integer_pat.match(x)
> it's about 2.3 times faster. C version would be even better.
>
> > 3) sqlhtml_validators is an obvious bug... 8/9 of work is wasted.
> > ... I suspect that dictionary building may be moved into module namespace
>
> did that with some tweaks (same validators get reused). Dangerous approach
> may introduce hidden dataflow, but that could be prevented by somehow making
> these validators read-only.
>
> Got another 9.5% model time speedup. (0.096s vs 0.106s). Though this figures
> get more and more meaningless as model init time reduces it's share in total
> page generation time. Probably I'll just switch to time measuring of
> urllib.urlopen().
>
> ...OK, switched. Here are stats. Each line is in the format
> model_init_time/urlopen_measured_time - average over 100 calls
> These timings are not comparable with my previous emails because I did some
> additional arrangements that should make these times more than usual, but
> more stable across tests. Also application is compiled this time.
>
> 1) no optimisations
> 0.1219/0.1649
> 2) skip CREATE TABLE in SQLTable init
> 0.0865/0.1261
> 3) + three steps, described above in this mail.
> 0.0439/0.0855
> 4) + lazy tables init in model
> This one is application specific. For instance in my application it causes
> 4 tables out of 16 to be initialised in model and 2 more - in controller. This
> is for front page. Other pages will have different figures. Yet, here are
> timings:
> 0.0194/0.0622
>
> 5) And finally, for mere comparison, timings of (4) again, but this time with
> non-compiled source.
> 0.0208/0.1216
>
> Some conclusions:
> 1) always compile your app for production. It saves you about 50% CPU.
> 2) With very little effort it was possible to speedup web2py app further 2.65
> times, dropping page generation times from tenths of second to hundredths.
> I hope at least some of that work will find it's way into mainline. I'm
> attaching all patches that I used to this mail. These patches are against
> quite old web2py - Version 1.61.4 (2009-04-21 10:02:50) (I didn't like how
> newer versions looked like so I stick to initially installed version).
>
> --
> Sincerely yours
> Alexey Nezhdanov
>
> is_integer.diff
> < 1KViewDownload
>
> lazy_define_table.diff
> < 1KViewDownload
>
> validators.diff
> 1KViewDownload
>
> no_dir_check.diff
> < 1KViewDownload
>
> skip_create_table.diff
> < 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 web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
