Steve Stewart <[EMAIL PROTECTED]> writes: > Hi folks, > > Whether it was UCSD Pascal, Java, or whatever, I never much > liked the idea of virtual machines hogging memory and > intermediate bytecode being compiled every time it executes.
I know what you mean, and I understand your concern. Having said that, I think Derby is better than many other Java apps out there. At least that has been my experience. > Garbage collection never seems to be very reliable, among > other things. I have profiled Derby (running TPC-B like load) and the gc graphs showed that a running Derby system spends very little time doing gc. My understanding is that this is by design. > Now that Fedora, for example, ships with native Eclipse and > Tomcat compiled with gcj, I wonder what the prospects are > for a native Derby? I guess you have already seen a posting from someone wanting to do this. It is an interesting idea and I hope they succeed. It would be interesting to see what kind of benefits it would give. The conventional wisdom is that in database system the cost of starting the jvm and getting the full effect of HotSpot compilation can be ignored since the system is expected to run for a long time. And then the benefit of compiling everything to native code would be marginal. But this assumption may not necessarily hold for all applications that would like to embed Derby... > I realize Derby requires, for instance, a JDBC client, which > relies, in turn, on java.sql and javax.sql, but isn't the > FSF Classpath Project already addressing such issues? Could be, I don't know :) Do you have an URL? -- dt However, experience shows that for many people and many applications a dose of paranoia is reasonable - Bjarne Stroustrup
