Further to , Malek Hadj-Ali (lekma) reported the script that use to take 4min+ is now under 2. There were still some strange bugs in http 1.1 with hessian and the request still eats 300Meg of memory. But, as Reinhard Müller (reinhard) noted at least for speed we're not magnitudes away any more. Malek did further testing, and noted that a hessian dump run independantly took a fraction of a second - the same hessian dump via the GNUe Application Server took 26 seconds. Reinhard noted that it was not unusual to see odd results like this when profiling python code - I suspect all the hidden python magic like garbage collection and the like has a big impact on performance - and the decision when exactly python runs the garbage collection might depend on conditions that we as humans would regard as "random". Jason Cater (jcater) wondered if using unicode, or the presence of the python psyco module was making a difference, but neither of these proved to be the case. Both Jason and Reinhard volunteered to have a look at Malek's code to see if they could spot anything.

The next day, Malek reported that he had figured it out - a bug in hessianlib that shown itself when dumping instances. He did some more tests with various different combinations (using XML-RPC, hessian and direct database access, both with and without GNUe Application Server) and found that hessian was still somewhat faster than the original XML-RPC protocol that GNUe had been using previously, but felt a bit frustrated that it should be significantly faster - as pure dumps/loads is around 3 times faster in hessian than xmlrpc.

The next day, Reinhard said he would apply Malik's patch so others can have a look and a try. Malek explained that his patch fixed a bug withe the hessian lib - but that don't solve all performance issue. Jason noted that his profiling tests conmfirmed this - I wrapped the calls into the hotshot profiler the other day - and noticed that most of the wait was inside of the networking code of hessianlib.py. Malek pointed out that appserver adds a non negligeabable overhead in ClientAdapter and ServerAdapter, regardless of whether hessian or XML-RPC was used, but it tries hard to balance this overhead with agressive http 1.1 connections - so all in all it's not that bad..

James Thompson (jamest) asked how stable is forms head? and the wx driver in particular - 2.6 as the dropdowns in the old wx driver have started causing us lots of issues. Reinhard Müller (reinhard) replied head should be perfectly usable, and wx26 should be possibly the most stable driver of all (as previously discussed in and similar threads). But he cautioned that this did not mean that you *won't* hit bugs.... James tried it, and noted 2.6 computes spacing a bit different than 2.4 did doesn't it? Johannes Vetter (johannesV) explained spacing depends on the biggest control possible - depending on the platform used. Reinhard clarified it just takes standard entry size, standard button size, standard dropdown size - and takes the biggest of them - so no control will get chopped. James was concerned that this really increases the horizontal space usage though - like on a rows=10 - it looking like whitespace is doubled.

Reinhard wondered whether widgetWidth and widgetHeight point sizes could be a configuration option - and if set override the auto dectected widget sizes. Johannes said that this should be handled quite well if there are layoutmanagers .... But James noted that this would also need to take account of what X themes the user was running - as for whatever reason themes effect forms here - a form that fits on user A's screen doesn't on User B's. Reinhard agreed that the only real solution is layout management - a button simply *isn't* of the same size as an entry for example.

James Thompson (jamest) noted that the two biggest things stopping me from opening forms are lack of support for integer and boolean typecasts - the typecast-attribute only seemed to support date, text and number as of time of writing. He asked is there a reason we don't don't support typecast= boolean or integer in GNUe Form Definitions? Reinhard Müller (reinhard) replied I have no idea, the set of possible values was defined ages ago - but it was never checked. I am not opposed at all to add any other values to the list as you see fit.