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

Ok, I think I am on a possible path.
I am testing '.apply()'.

1) I did again notice & verified that a xwar gets parsed/tested on load: 
(as just a directory this doesn't happen)
...
           Resources: done loading archive
                Main: loading xwar from local filesystem
...
           Resources: WARNING: ignoring xwar entry with invalid name: 
#main_tests2.xwt~
...
            Template: error parsing template at testsWErrors:13,2
            Template: invalid Character Entitiy
            Template:    <<No stacktrace available>>
...
           Resources: done loading archive
...
MessageQueue$Message: note: executing same trap for 1s at null:0
            JSObject: Context.getCurrentContext() is null in 
getCurrentFunctionSourceName()
  Win32$Win32Surface: disposing org.xwt.plat.Win32$Win32Surface@2b1a300
  Win32$Win32Surface: disposing org.xwt.plat.Win32$Win32Surface@f5d880
                   0: new thread
                   0: apply
                   0: applied

2) The interesting thing is that the startup time is reasonable 
(eventhough it contains the 'slow' files, that do get parsed. [I tried 
adding a '&' or other trash in the tree or other files (eventhough 
nothing references them) and I get an error in the log for each.]

Anyhow I think this method will aid getting past the very slow startup.

Thanks for the help.

-Jeff


Jeff Buhrt wrote:

> 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.
>>
>>  
>>
>
>
>
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.xwt.org/listinfo/users
>