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?
* Is VFS3 in trunk/ now?
* Did somebody look into whether code guards are being done for logging?
* 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.
* 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 rebooted
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