Hi,
On Sat, 24 Nov 2001 22:23, Paul Hammant wrote:
> >Kool. So my wish of running Phoenix on a tank is looking better ;)
> >
> >I know of a few areas in which Phoenix memory / resource usage would need
> > to be improved before it could run comfortably in such an environment. In
> > particular the following could be big issues.
> >* threads
> >* classloader
> >* xml processing
> >* logging
> >
> >ClassLoader is probably the least of the worries but each of the others
> > will need triming. Tell us how first run goes and which parts cause the
> > most pain for you ;)
>
> Maybe trimming is not the right term. Perhaps multiple implementations
> is the right way of curing the issue.
Well in some cases the exisitng components can be trimmed. They are a bit
innefficient but because these inneficiencies are so minor in a server
environment (who cares if you use 200 k vs 800 k to cache startup values -
who even cares if you never release it over life of app) but could become
issues in a memory restrained device.
For other components (ie logging and xml processing) we could replace them
outright with slimer versions.
> If logging can be configured to do
>
> a) expanding log file(s) as at present
> b) rolling log file(s).
> c) logging to null:
> d) logging mapped to System.out
When we goto beta we will remove direct references of LogKit from Block
definition and you could replace logging with a lightweight object that just
printed to stdout if we wanted.
> I'm not sure what is wrong with threads, classloading and xml
> processing.....
We create quite a few threads, some of which we leave in suspended, waiting
to be signalled (ie like main Phoenix thread) or whatever. We could optimize
them out - just a bit more effort that hasn't been needed yet ;)
And the XML parser we use now, while complete is not the most lightweight
version around.
> Cornerstone now presents DOM & SAX parser factories to
> host apps through component manager. Is it that we could be having
> needless multiple instances in one phoenix VM? Or are you thinking just
> about general resource use?
more general resource usage.
> As for the breakthough moment with the iPAQ, it is some time away as
> I've no way at present of getting file to it *after* SavaJe has been
> installed. The only supported ways need extra hardware, PPP over serial
> cable not implemented yet.
ug.
> An alternate stategy could be to replace the jar file that is being
> burned in to eeprom with one of our making with Linux's mkcramfs tool.
Peter + hardware == scratch head, shrud then smile and nod
;)
--
Cheers,
Pete
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
