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

Emiliano,

#3 is the most important idea/question.

1. This is currently in Lithium on XP directly using xwt-0218.exe, which 
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.

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.
-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)
    -I saw how 'apply' can load xwars, but didn't see how to pass a box 
down the wire...
    -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.

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.
b) A cardpane with 332 'screens' takes 5min 17 sec to load.
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. For the first ~75% memory is fine 
and processor is near 100%, furing the last part the system is paging.

Thanks,

-Jeff

Emiliano Heyns wrote:

>On Tue, Oct 28, 2003 at 05:29:37PM -0500, Jeff Buhrt wrote:
>
>  
>
>>Right now I am fight nasty startup times using Li and I am thinking of 
>>stripping out everything I can and then sending down my screens as 
>>needed. I am also thinking of trapping each node of a tree send down 
>>only what is needed at that time, in addition of either fixing <tree> or 
>>hoping for Nitrogen to be better.
>>[I am at 5m17s without a tree and 17m45s with the tree, something has to 
>>change.]
>>    
>>
>
>_Yo!_ *That* ain't good. Which engine are you using? The java version?
>Does the 17m include the download of the engine, or is it the time from
>splash to first widget being drawn? And that would be using vs not using
>the tree, right? Not just having it present in the xwar?
>
>Stripping might help a bit, but the widget set is only some 500k at the
>moment... the download time won't make too much of a difference (to me,
>at least), and downloaded-but-unused widgets should not have any impact
>on startup times or performance thereafter (right, charlieg?).
>
>I realize Ni is pretty young, but given that the pre-Ni widget sampler
>showed quite some interesting things this sounds like a major
>regression problem.
>
>  
>