On Mon, 27 Dec 2004 22:53:05 +0900, David Leangen <[EMAIL PROTECTED]> wrote: > > > Hi, Werner, > > I think you hit the nail on the head. I guess my major problem is not the > classloading itself, but the fact that I left out the word "framework" when > dealing with Castor. In truth, I lost sight of the fact that it is not > always appropriate to use a framework. > > As you mentioned, in many, if not most cases, the initial startup time is > not important. I'll just have to be more realistic in those rare cases where > I need to avoid the overhead of class loading and avoid a "framework" like > Castor and just jump in directly with good 'ol SAX. In most other cases, > however, when using Castor is appropriate, I'll try to think of ways to > initiate the classloaded before hand during system initialisation and not at > the time of a user's request. > > Thanks for bringing me back to reality. ;-) > > And I will try out your suggestion and run a more valid test 100 times or > so. I'll report back to you with the results if I find anything interesting. > I don't expect to get around to that for a while, though...
Dave, You really never know what is going to happen to code once it is passes through the JIT compiler. The "if" statement may be converted to a switch statement. The "if" statement may be inlined. The only way to tell is to time the code in isolation. Can you write a test case that tests just the parser code in isolation? If you can write a isolated test, don't forget to run the test twice to force the JIT compiler to kick in and then throw out the first result. One final thing, a VM can't really accurately measure a single period shorter then 500 ms. I normally do some work in a for loop with a few thousand or million iterations depending on the thing being measured. I time the entire loop, and divid by the number of iterations to get to the time for a single loop (normally in nanoseconds). FWIW, Werner's suggestion is absolutely correct. Make sure that you run the test at least twice to get the JIT compiler to kick in and then discard the result of the first run. You do this because the JIT hasn't kicked in yet and because of the initial classloading that must take place. In fact, I might go one step further and suggest running the test thousands or even millions of times (depending on what you're testing exactly), discard the results of the first iteration and then divide the results by the number of iterations to derive the real results. The reason for this is that the VM can't really accurately measure a single operation shorter than 500 ms. Also, remember that the Java VM is not going to load any classes that it does not need. Therefore, a smaller jar is not necessarily going to speed up much. Another thing to remember with XML parsing is that the actual parsing will definitely have a good amount of overhead associated with it simply due to parser overhead. There is very little that can be done to avoid this as the parser is outside of our control. However, you can try to use different parsers via the org.exolab.castor.parser property in the castor.properties file. One last thing, I know that there is a bug out there on the Castor JDO side that I think is fixed in the latest release (which Werner is still working on I think) where object creation is sped up dramatically by introducing the use of cglib (http://cglib.sf.net/). Depending on how this works out, it may be something we want to try on the XML side if possible. But this is just a thought off the top of my head as I have not investigated even the possiblity of doing this on the XML side. Bruce -- perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/ ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-user
