On 11 Feb 2010, at 23:23, Bill Burke wrote:
BTW, my guess is that it is file caching. Good job though! Almost a
full second shaved off. Nothing to sneeze about.
So what's next for optimization?
In dependency the things which had the biggest
impact were not breaking out of the resolveContexts() loop and that AbstractDependencyItem
was calling controller.getContext() three times when a dependency is not there yet.
For me, profiling the whole app server startup gives too much information and different
hotspots don't really stand out that much. I'm creating a series of
micro-benchmarks to profile different areas in isolation. Next is trying the different
things in jboss-kernel, which is more interesting since it pulls in things like MDR and
jboss-reflect. I'll have a look at the ScopeKey lookups I mentioned in
today, before trying out other parts of
* Is VFS3 in trunk/ now?
* Did somebody look into whether code guards are being done for logging?
I believe Ales did this for MC
* Any possible improvements to creating BeanMetaData?
* How about making our bean.xml files more coarse grain? Meaning *A
LOT* less implementation details exposed through XML. You can do IoC in
Java you know. The vast majority of details within all our beans.xml
files will never ever change, nor will we want to support users changing
this stuff. If our beans.xml file are reduced to a few bean definitions
and classes, would make parsing and creating bean metadata much much faster.
somebody wants to look into that, some help would be welcome. I've got a feeling my
hands will be full the next few weeks :-)
* I also could resurrect Fast-JAXB, but I didn't want to do that until
we got under 10 seconds.
For the MC team, I think the biggest focus should be profiling and
Kabir Khan wrote:
> I actually did a few runs on each server first, but had loads of apps open so I
> On 11 Feb 2010, at 12:33, Jaikiran Pai wrote:
>> Kabir Khan wrote:
>>> One strange thing is that the first time I started each server they took
loads longer than the other times, does somebody know the reason for that?
>> Wild guess - Perhaps, JBoss Messaging takes time to create the JBM
>> tables for the first run. The second run the tables are already present
>> in JBOSS_HOME/data folder so i guess it's skipped. Maybe deleting the
>> data folder before starting the server, the second time, will show no
>> significant difference between the two runs.
>> jboss-development mailing list
> jboss-development mailing list
JBoss, a division of Red Hat
jboss-development mailing list