From owner-freebsd-java Tue Jun 8 13:11:18 1999 Delivered-To: freebsd-java@freebsd.org Received: from aurora.rg.iupui.edu (aurora.rg.iupui.edu [134.68.31.122]) by hub.freebsd.org (Postfix) with ESMTP id 5E667154DB for ; Tue, 8 Jun 1999 13:11:02 -0700 (PDT) (envelope-from gunther@aurora.rg.iupui.edu) Received: (from gunther@localhost) by aurora.rg.iupui.edu (8.8.7/8.8.7) id PAA22114; Tue, 8 Jun 1999 15:15:39 -0500 (EST) (envelope-from gunther) Date: Tue, 8 Jun 1999 15:15:39 -0500 (EST) From: Gunther Schadow Message-Id: <199906082015.PAA22114@aurora.rg.iupui.edu> To: freebsd-java@FreeBSD.ORG, shudoh@muraoka.info.waseda.ac.jp Subject: My "benchmark" ... Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello again, here is my promised "benchmark". This is my real application that I am working on that creates thousands of objects from data received over the net and also from a local data base, using XML encoding of objects. I have written a JNI wrapper around GDBM since I didn't know that w3c's Jigsaw project brought forth a 100% pure Java "jdbm" class. So, now I have the option of both, native GDBM or 100% pure Java. Here are the results: No JIT -GDBM -JIT real 3m21.629s user 3m4.319s sys 0m0.939s -GDBM -JIT (32Mb heap) real 2m29.798s user 2m7.476s sys 0m1.164s +GDBM -JIT real 2m52.773s user 2m33.531s sys 0m0.759s +GDBM -JIT (32Mb heap) real 2m16.742s user 2m1.389s sys 0m0.991s TYA -GDBM +TYA real 1m53.723s user 1m29.372s sys 0m1.028s -GDBM +TYA (32Mb heap) real 1m18.765s user 0m35.960s sys 0m1.189s +GDBM +TYA impossible (VM melt down) shuJIT -GDBM +SHUJIT real 2m17.876s user 1m56.686s sys 0m1.248s -GDBM +SHUJIT (32Mb heap) real 1m43.735s user 0m59.094s sys 0m1.520s +GDBM +SHUJIT real 1m55.101s user 1m32.320s sys 0m1.080s +GDBM +SHUJIT (32Mb heap) real 1m28.916s user 0m55.645s sys 0m1.154s Conclusions: A JIT speeds up almost by a factor of 2. TYA is a little faster for me than shuJIT. ShuJIT, however, does not crash with the native GDBM. On the other hand shuJIT crashes on a randomized basis. The native part turns out to be less critical than an initially large heap size. However, the native part does speed things up. Interestingly, the combined effect of large heap size and native has less effect than the sum of each optimization applied separately. Finally, Java object serialization which I have found to be slower than manual XML coding. The dramatic performance increase gained by using a JIT is very promising. With a little tweaking I can probably get some acceptable upload speed :-) Read from Java object stream only GDBM no JIT real 0m36.158s user 0m32.135s sys 0m0.256s shuJIT real 0m19.741s user 0m15.977s sys 0m0.170s Thanks Albrecht, thanks Kazuyuki! BTW, would it make sense to combine TYA and shuJIT to leverage the strengths of both? Have you guys looked at each other's code? regards -Gunther Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu Regenstrief Institute for Health Care 1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960 schadow@aurora.rg.iupui.edu ---------------------- #include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message