Alexey,
custom.widget is already in trunk
On Tue, Jun 9, 2009 at 2:14 PM, Alexey Nezhdanov<snak...@gmail.com> wrote:
> Finally, I started migration (before I was just slapping sql.py, checked out
> of the trunk over my ancient 1.61.4 install).
> Migration is not easy, I've been bending source for my needs so now I have
> to port all this to 1.63.5. Massimo, do you have any objections to this
> patch? I proposed it some time ago, but you were too busy at the time.
> The purpose is - if we want custom forms instead of SQLFORM then we have to
> write our own view.html. But on the other hand - that is double work in the
> regard that we need to write down <input type='xxx' length='yyy' id='zzz'
> name='nnn' /> each time while we already generated all this in controller.
> I'd really like to be able to write in my controller:
> <table><tr>
> <td>{{=form.custom.label.my_input}}</td>
> <td>{{=form.custom.widget.my_input}}</td>
> </tr></table>
> See attached patch.
>
> On Tue, Jun 9, 2009 at 3:14 PM, Alexey Nezhdanov <snak...@gmail.com> wrote:
>>
>> Forgot about patches. Here they are.
>> 'optimised inits v.2'
>> 'lazy tables' (this one is modified to be applicable to trunk version of
>> sql.py)
>>
>> On Tue, Jun 9, 2009 at 3:10 PM, Alexey Nezhdanov <snak...@gmail.com>
>> 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<snak...@gmail.com>
>>> 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<snak...@gmail.com>
>>> > 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<snak...@gmail.com>
>>> >> 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<mdipie...@cs.depaul.edu>
>>> >>> 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 <m.grit...@gmail.com> wrote:
>>> >>>>> On Mon, Jun 8, 2009 at 5:54 PM, mdipierro<mdipie...@cs.depaul.edu>
>>> >>>>> 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
>>> >>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
