*** reinhard has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<reinhard> good morning all
*** btami has joined #gnuenterprise
<btami> good morning
*** SachaS has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** kilo has joined #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> good morning
<kilo> good morning
<lekma> johannesV_: do you have some time to spare for me?
*** SachaS has quit IRC
<johannesV_> lekma, sorry ... i'm quite busy atm
<lekma> ok, np
<johannesV_> maybe i can play with profiling appserver during the weekend
*** btami has quit IRC
<reinhard> hmmm
<reinhard> before: 6.4 seconds
<reinhard> after: 0.7 seconds
<reinhard> does this sound like an useful optimization?
<kilo> make it 0.6 :)
<lekma> what opti is that?
<lekma> make it 0.5 :)
<reinhard> on level of datasources
<reinhard> I introduced a way to skip off the whole overhead of ResultSet and RecordSet in cases where you don't need it
<lekma> when do you need it? calc props?
<reinhard> no
<reinhard> you *never* need it for appserver, you only need it for forms
<lekma> woot
<lekma> \o/
<reinhard> but as using the same datasources library for forms and appserver, it had a lot of overhead that was only for forms
<reinhard> like tracking dirty records, caching, etc
<reinhard> which is anyway done in appserver itself (and not used from this library)
<reinhard> for jcater and the logs: this might also be interesting for reports, as AFAICT reports should also be able to work without that overhead
<reinhard> as a side effect, it should also greatly reduce the memory footprint
<kilo> wow wow wow
<reinhard> lekma: before you fall into rejoicing
<kilo> i hope you have no other programmes for the weekend :)
<reinhard> this is only a part of the performance loss in appserver
<reinhard> hmmm.... for reports, the missing master/detail ability might be a problem...
<reinhard> too funny
<reinhard> just testing the performance of direct dbsig2 data access
<reinhard> for 100000 records
<reinhard> pygresql: 26 seconds
<reinhard> pypgsql: 28 seconds
<reinhard> psycopg: 0.8 seconds
<lekma> impressive
<reinhard> psycopg rocks my socks
*** kilo has left #gnuenterprise
<reinhard> gnue-common high performance access on psycopg: 6.3 seconds
<reinhard> so common adds even less overhead than pygresql now :)
<lekma> high performance access == a way to skip off the whole overhead of ResultSet and RecordSet ?
<reinhard> yes
<reinhard> not the whole overhead, but the whole *unneeded* overhead :)
<reinhard> johannesV_: if you want, you can try to change data.py to make use of the new ResultSet.raw() function
<reinhard> otherwise I will try to do it this evening
<reinhard> so you and lekma can test overall performance hit
<reinhard> off to garden work now
<lekma> i can test tomorrow
*** btami has joined #gnuenterprise
*** derek_ has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** dimas__ has joined #gnuenterprise
*** dimas__ has quit IRC
*** reinhard has left #gnuenterprise
*** reinhard has joined #gnuenterprise
*** lekma has quit IRC
*** klasstek has joined #gnuenterprise
*** johannesV_ has quit IRC
*** johannesV_ has joined #gnuenterprise
<johannesV_> reinhard, if you can do that change to data.py i'm ok with it ... as it seems i'll have not very much time to do so the next days ...
<reinhard> ok
<reinhard> am already at it
<reinhard> nice
<reinhard> on data.py level
<reinhard> before = 22 seconds, after = 13 seconds
<reinhard> down at 9 seconds now
*** psu has joined #gnuenterprise
<reinhard> python profiling is full of surprises
<reinhard> changing a single "foo = '%s-%s' % (bar, baz)" into "foo = bar + '-' + baz" increased overall appserver performance by  > 5%
<nickr> I noticed some interesting stuff like that
<nickr> Like string appending is way faster than multiple file writes
<nickr> maybe thats just on windows though.
*** psu has quit IRC
<johannesV_> hm, that's strange ... as it was documented somewhere, that "%(foo)s" % {'foo': 'somevalue'} is faster than 'foo' + 'bar'
<johannesV_> and more readable
<johannesV_> reinhard, have you tested that with timeit.py too ?
<reinhard> I will test again
<reinhard> as my change also invoved getting rid of an implicit string to unicode conversion
<johannesV_> yeah
<johannesV_> but i think that changing __has() and the like gains much more :)
<johannesV_> as i also read about using try: except KeyError: to improve dictionary-checks
<johannesV_> where the big point is catching the KeyError only :)
<johannesV_> if that would be omitted (so catching everything) would slow down things dramatically
<johannesV_> as you've said before, profiling is full of surprises :)
<johannesV_> but the improvements you've done so fare are great  ... the benchmark took 21 seconds before, and 8 seconds after the change of data.py
<johannesV_> ok, i'm off for today ..
*** johannesV_ has quit IRC
*** btami has quit IRC
*** sjc has joined #gnuenterprise
*** jcater has left #gnuenterprise
*** kilo has joined #gnuenterprise
*** lupo__ has joined #gnuenterprise
*** kilo has left #gnuenterprise
*** klasstek has quit IRC
*** lupo__ has quit IRC
<reinhard> good night all
*** reinhard has quit IRC
*** sjc has quit IRC
*** SachaS has joined #gnuenterprise
*** SachaS has quit IRC
*** SachaS has joined #gnuenterprise
*** dsmith has joined #gnuenterprise
<dsmith> Howdy gnue dudes