Re: [xwt-users] perl script to strip an xwar

On Tue, Oct 28, 2003 at 09:07:34PM -0500, Jeff Buhrt wrote:

> 1. This is currently in Lithium on XP directly using xwt-0218.exe, which 

That's not so good.

> is what most desktops will be running.
> My testing is a local 100Mb network and a Samba share, either with an 
> xwar or the xwar extract in a directory. Timing is the same, except in 
> the xwar I get the progress bar on the startup screen.
> The test client (xwt) machine is XP on a P4 2.2Ghz 400Mhz FSB, 512MB memory.

Under these circumstances, the download-size issue is not going to be
part of the problem.

> 2. My thought of the request was:
> a)  to strip the unneeded things out of the xwar as step one. To make 
> the general startup quicker. Not much but it gives a quicker 1st screen.

Very important. If nothing happens for a long while, people will assume
something is wrong.

> -Note in Li anything in the archive must be parsed. If I leave a file 
> with a bad name, mistakes, etc. it will show in the log.
> b) Load only the login and support logic into the xwar.
> c) Figure out how to send boxes down the wire (and/or only load as 
> needed, see #3)

You can do that with Ni, and that should indeed make the splash display
quicker, but I still wouldn't tolerate a 17m delay after that.

>    -I saw how 'apply' can load xwars, but didn't see how to pass a box 
> down the wire...

Resource fetch, I think.

>    -Tomorrow I am going to try to find a way to do this.
> -Nitrogen's being able to use a web 'directory' and dynamically bring 
> files down, that would help.

A web directory... interesting thought. WebDAV, anyone?

> 3. Is there any way to not load and parse a .xwt file inside an xwar in 
> Li at startup, but to delay until it is needed?
> -If I had a way to just use var boxName="myBoxN"; ...blah["$" + boxName] 
> that would get around having to parse everthing at startup.
> -Worst case I put each 'screen' in its own xwar for now.
> -If I can do this, then I can load the tree by section on each trap, and 
> only bring in screens that are needed.
> 
> 4. This appears to have to do with having a lot of boxes.
> Some timings for example: [All these are about the same for a directory 
> or xwar.]
> a) a <tree> with 153 nodes and 506 leafs takes about 2m30s.

That's pretty bad. That is only a very tiny fraction of what would
describe my mail folder, for instance.

> b) A cardpane with 332 'screens' takes 5min 17 sec to load.

I'd say a cardpane with that many screens is a-typical (and a usability
nightmare), but it ought to render faster.

> c) If I add back the tree (above) the XWT startup becomes 17min 45s.
> I think a lot of the speed problems without the tree is memory. It was 
> at 591MB and about 395MB+ in memory.

*Oof*

> For the first ~75% memory is fine 
> and processor is near 100%, furing the last part the system is paging.

Adam, Charlie... without wanting to be all too critical, these things
sound like catastrophic regression problems. A web application that
takes 17m to start and consumes some 400MB memory is unacceptable. This
could just be the totally valid principle of 'get it to work, then to
work well, then to work fast', so me fretting about this could be
premature, but if performance tweaks are possible and expected, I'd love
to hear about it.

-- 
Emiliano