>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.

>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 ;-)

>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.

>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?

regards

thomas

>
>>Interesting. The 2 possible scenarios (either something like Electron RPCing the local app enhanced with HTML/XML generation or deploying FIC locally) of providing the web GUI as a locally installed and performed application probably would be close in speed, provided a local FIC could skip form save/restore in most cases by caching, as the user most of the times works on the same form.
>>
>>many thx for the data - even if 13% are missing ;-))
>>
>>thomas
>>
>>>>>Desktop app is about 4 times faster than the Web app (server overhead), GUI is much rougher (see attached)
>>>>
>>>>As you often take the time to measure exactly, did you measure which parts slowed down to what percentage or try out running the browser on the machine working as server ?
>>>
>>>FAS does that automatically per request, min, avg and max:
>>>
>>>avg based on 2,481 user actions from 31 unique users
>>>
>>>initializing request 1%
>>>restoring application state for user 0%
>>>restoring form state for user 12%
>>>application 23%
>>>updating menus 0%
>>>saving application state for user 0%
>>>saving form state for user 12%
>>>identifying visual changes 0%
>>>mapping visual changes into HTML 14%
>>>mapping visual changes into XML 4%
>>>cleaning up environment 0%
>>>Internet 16%
>>>Browser 5%
>>>FoxInCloud Application Response Total 100%