BTW... why you did not like the newer versions 1.63.5?
On Jun 7, 5:35 am, Alexey Nezhdanov <[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---
