>>You're right, that's the mystery of averages (sum of averages differs from the average of sum).
>>I was aware of an inevitable difference, I never checked how much it could be, and it occurs to be very significant ... Better take it as orders of magnitude.
>>
>>UPDATE: there is some discussion on this subject: http://math.stackexchange.com/questions/105463/sum-of-averages-vs-average-of-sums
>>There may be a glitch in our time measurement (calculation shared by browser and server, somewhat tricky)
>
>My belly guess was something eliminated during calculation or missing values.

Requires a review obviously


>>An other possible observation is that the web app saves time for GUI rendering as forms run hidden on the server (FiC uses the forms are logical containers, graphic displays occurs on the browser only). Though it's almost impossible to measure that on a desktop GUI, based on sight impression and for this particular app, GUI rendering takes almost as long as method code (seeing the controls flickering: combo boxes, grid, etc. until user can interact again).
>
>With screen locking before "big" screen updates I found that seldom to be a problem. Since most of the code I touch is well-layered, needing only a redraw of values calculated in other layers, I find no real problem as long as controls are close to the "metal" of base controls (even activeX)
>>FiC app always skips the 'restore' step when the same user fires another event on the same form (and parent form if running in default datasession) and on the same server (up to 32 servers can run simultaneously).
>
>So for the hypothetical "local FIC install" the restore time will be eliminated most of the time ;-)

yep

>>The 'save' step is almost mandatory (except for a very limited set of events) because FAS identifies changes by comparing the 'ante event' and the 'post event' states. Some expert argue that we could pick the changes on the fly, using techniques like this_access(), I prefer keeping this state comparison mechanism which is, IMO, easier to debug.
>
>My first gut reaction was that the "form save" should happen after (html/xml generation plus answer to browser). That way it would not influence the response time of the client, "only" taxing the server a bit more. Debug clearly helped by a pre-saved form state, but for hairy scenarios a special "pre-generate save" templatemethod could be called, or the save conditionally placed depending on a flag.
>But as you know your app, you probably had other technical reasons I am not aware of.

we need to save the 'post' state to figure out the changes compared to the 'ante' state
besides, a Web transaction needs everything done synchronously until the response is delivered


>>The downside is that the developer must list, for each object and classes, the native 'display' properties (.Visible, .Enabled and so on) that can change during a user event -- of course FAA does the job initially; later, when creating new functionalities, dev must either do it her/himself (it soon becomes automatic), or re-run FAA against the modified application.
>>
>>Another (very strong) lever to improve Web response time is to upgrade the server box frequently (say every year) -- Moore's law is still here.
>
>I was surprized the HTML/XML generation takes longer (multiple times!) than measured browser time. Of course such string handling will be faster in C/C++ code, but that one was the real surprise. "Internet" = Web server and transmission times lumped together?

This sample form has a grid, most often (and only when required) we need to regenerate the underlying script; fortunately FiC also logs that in the browser console:

'ip_scx-grd' grid script took 250 ms. to generate on the server, 184 ms to execute on the browser, total 434 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cscript_() - state changes > JavaScript: 141 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cxml() - current state XML 109 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cxml_rs_calias() - .RecordSource "WebTemp_Page" > RecordSet using Select-SQL: 47 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cxml_rs_calias() - Current record located using unique key expression "WebTemp_Page.UNIQUEID": 0 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cxml_rs() - 'WebTemp_Page' RecordSet > XML (11 rows): 0 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cscript_oxmlchanges() - state changes: 109 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cscript_rs() - data changes > JS: 0 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cscript_dynprops() - 16 ms.
awhtml.fxp!Awhtmlgen.gethtml_grd_aw_cscript_events() - event handlers: 109 ms.