te:
I have updated a web page showing results of performance measurement of
various Java runtimes.
Performance Comparison of Java/.NET Runtimes (Oct 2004)
http://www.shudo.net/jit/perf/
The benchmarks on the page are mainly compute intensive and not
server-side ones: SPEC JVM98, SciMark 2.0, Li
I have updated a web page showing results of performance measurement of
various Java runtimes.
Performance Comparison of Java/.NET Runtimes (Oct 2004)
http://www.shudo.net/jit/perf/
The benchmarks on the page are mainly compute intensive and not
server-side ones: SPEC JVM98, SciMark 2.0
(I've included some results from the AIM
Independent Resource Benchmark as well as the startup logs from the
kernel), and overall system performance appears to be fine. However,
Java performance, especially Swing, is horrible. When running a Swing
application (the Stylepad demo included
Actually
I’m writing a fullscreen game on windows with Java, Its going to run on
little embedded machines so I checked Linux before WinXP, but it runs really really
slower than linux, in a P2 2ghz I get on windows 80 fps, and in Linux ( same
computer ) 33 fps, I’m trying as m
I am actually running gentoo linux with glibc 2.3.1 which does not have the
LD_ASSUME_KERNEL option. From what I know, this forces glibc 2.1.3 (on
Redhat) to be used. However gentoo does not support this from what I can
tell. The system breaks when this variable is used.
On a performance note
Hi,
Remember that IBM-jvm needs the following environment variable:
LD_ASSUME_KERNEL=2.2.5
You could try this and see if page faults continue arising.
Regards,
Marco Trevisan
Narendra Sankar wrote:
hi
I ran a very simple thread creation benchmark on various vms to find out how
useful my
+0k 0+0io 2272pf+0w
time /opt/sun-jdk-1.4.1.01/bin/java -server Loop 32768
7.830u 6.730s 0:14.02 103.8%0+0k 0+0io 2295pf+0w
I see that the IBM jvm gets the best performance, but has the most number of
page faults. So the real world time is the highest. Can anyone explain this?
Also why is the
I would be more than happy to help with builds of the Blackdown JVM.
What do we have to do to get CVS access?
Narendra Sankar wrote:
Hi Everyone
Since I discovered Jedit, I have been looking into jvm performance,
specifically on linux as that is my platform of choice. I love jedit and it
has
Hi Everyone
Since I discovered Jedit, I have been looking into jvm performance,
specifically on linux as that is my platform of choice. I love jedit and it
has all the features for me - but I primarily develop in C and C++. One of
the problems I have seen is the slow performance on linux. I
performance analysis tool for
mysql.
Reg
Ved
-Original Message-From: Ramasubramanian
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, December 26,
2001 4:47 AMTo: [EMAIL PROTECTED]Subject:
Measuring MYSQL Performance
Hi,
Is there
any way by which the performance of MYSQL could
Hi,
Is there any
way by which the performance of MYSQL could be measured in JDBC for Linux
?
Regards
Rams
- Original Message -
From: Ramasubramanian
To: [EMAIL PROTECTED]
Sent: Monday, December 24, 2001 4:56 PM
Subject: Performance Analysis Tool in jdk1.1.8
Hi All
Hi All,
Can u please suggest a performace analysis tool compliant for
jkd1.1.8 under Linux which would give me information reg. the memory and CPU
utilization, number of threads spawned etc. ???
I find lots of tools that are compliant with the Java 2
platform but no
ouse events. Other X
> > > > applications
> > > > including emacs and Mozilla are quite usable over the same link. What is it
> > > > about
> > > > Swing and/or AWT that causes this horrible performance. Is there anything
> > > > that can
&
On Thu, Mar 08, 2001 at 09:36:11PM -0800, [EMAIL PROTECTED] wrote:
> do you reconize me you asses its me
>
> YOURS SINCERELY
> Shivakanth
$ cat >>~/.procmailrc
:0
* ^From [EMAIL PROTECTED]
idiots
:0
* ^From: [EMAIL PROTECTED]
idiots
:0
* ^From: "Mr.Y.SHIVAKANT" <[EMAIL PROTECTED]>
idiots
--
t; machine to another across an ISDN line. Performace is horrible, it takes a
> > > long
> > > time to open windows, display menus and react to mouse events. Other X
> > > applications
> > > including emacs and Mozilla are quite usable over the same link. What is it
&g
"Martin, Stephen" wrote:
>
> > See the suggestions in
> > http://developer.java.sun.com/developer/bugParade/bugs/4204845.html
> > Do any of those help?
> > - Dan
>
> This and all the rest of the replies have been excellent. Clearly Sun is
> aware of the problem and from reading the posts attache
On Tue, 6 Mar 2001, Jesus M. Salvo Jr. wrote:
> SUn's Bug Parade did say that Swing on remote X IS slow. The workaround
> is not to use double-buffering:
>
> http://developer.java.sun.com/developer/bugParade/bugs/4204845.html
Something else to do is to use a stream compressor to compress the
d
> See the suggestions in
> http://developer.java.sun.com/developer/bugParade/bugs/4204845.html
> Do any of those help?
> - Dan
This and all the rest of the replies have been excellent. Clearly Sun is
aware of the problem and from reading the posts attached to the bug
it is clear that the user com
s, display menus and react to mouse events. Other X
> > applications
> > including emacs and Mozilla are quite usable over the same link. What is it
> > about
> > Swing and/or AWT that causes this horrible performance. Is there anything
> > that can
> > be done about it.
cations including emacs and Mozilla are quite usable over the same
> link. What is it about Swing and/or AWT that causes this horrible
> performance. Is there anything that can be done about it.
See the suggestions in
http://developer.java.sun.com/developer/bugParade/bugs/4204845
On 2001-03-06 15:48:55 +0100, Martin Schröder wrote:
> On 2001-03-06 08:35:32 -0500, Martin, Stephen wrote:
> > Swing and/or AWT that causes this horrible performance. Is
> > there anything that can be done about it.
>
> Use jdk 1.x
s/1\.x/1\.1\.x/
Be
orrible, it takes a
> long
> time to open windows, display menus and react to mouse events. Other X
> applications
> including emacs and Mozilla are quite usable over the same link. What is it
> about
> Swing and/or AWT that causes this horrible performance. Is there anything
>
On 2001-03-06 08:35:32 -0500, Martin, Stephen wrote:
> Swing and/or AWT that causes this horrible performance. Is
> there anything that can be done about it.
Use jdk 1.x
Best regards
Martin
--
Martin Schröder, [EMAIL PROTECTED]
ArtCom GmbH, Grazer Straß
use events. Other X
applications
including emacs and Mozilla are quite usable over the same link. What is it
about
Swing and/or AWT that causes this horrible performance. Is there anything
that can
be done about it.
Steve
--
To U
On Wed, Oct 11, 2000 at 02:11:51PM +0300, Ganesh Sivaraman wrote:
>
> Is there any kind of JVM performace check tool, which can show the
JProbe, http://www.klgroup.com/jprobe/
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
--
Hi,
I had posted this a while ago.
I am reposting with some hope that I will be able to get some response
this time.
Is there any kind of JVM performace check tool, which can show the
applications memeory consumption processor load and other parameters. It
will be great to have this in Java as
Hi,
Have you done any performance test for any Java graphical applications for
Linux. What I am interested is to find out the performance of Linux with X
and Linux without X. So is there any performance software that can be used
for this. This means that the progs should be in Java. I have tried
Hi folks,
I've measured performance of JIT compilers which work on Linux.
If you're interested in, please see
http://www.shudo.net/jit/perf/
Evaluated runtime systems are IBM JITC (in IBM JDK 1.3 and 1.1.8),
HotSpot Client and Server VM in Sun JDK 1.3, JIT v3 in Kaffe 1.0.6,
JBuil
Miles Sabin <[EMAIL PROTECTED]> writes:
> Agreed. One big headache is the fact that asynchronous IO
> (POSIX or otherwise) is typically going to require that buffers
> be at fixed addresses, ...
> I guess that in principle it ought to be possible to tweak
> JVMs to special-case a priviledged clas
would be REALLY
nice. Given Java's bounds checking though, at best it'd have to be
some kind of struct, rather than a raw pointer.
> Also, in the case of GetArrayElements(), the JVM does not
> promise not to copy the data -- and copying kills your performance.
The JVM has the option
s a Java object - not the other way around.
What you are talking about is getting a C pointer to a Java object.
Not the same thing!
Also, in the case of GetArrayElements(), the JVM does not
promise not to copy the data -- and copying kills your performance.
Matt Welsh
---
On Wed, May 10, 2000 at 01:10:20PM +0100, Miles Sabin wrote:
> Matt Welsh wrote,
> I guess that in principle it ought to be possible to tweak
> JVMs to special-case a priviledged class of byte[]s to allow
> them to be pinned for an extended interval without completely
> screwing GC, but I'm not at
Matt Welsh wrote,
> My personal feeling is that there is a lot that will need to
> happen at both the Java and the O/S level to get great I/O
> performance. I am not sure I agree with many of the
> discussions in the linux-kernel list that the right way to
> get high I/O bandw
Expert Group for JSR 51 (the new I/O APIs for the Java
> platform), so hopefully good things will happen there!
Yes, it should be interesting!
> My personal feeling is that there is a lot that will need to happen at
> both the Java and the O/S level to get great I/O performance. I am n
Hi Dan,
> Anyone here interested in getting Java to handle heavy I/O nicely?
Exactly the topic of my research :-) You should check out Jaguar,
a system I have developed to do high-performance networking and I/O in
Java. It's at
http://www.cs.berkeley.edu/~mdw/proj/jagu
> Dan Kegel writes:
Dan> Anyone here interested in getting Java to handle heavy I/O
Dan> nicely? I'm personally interested in insane things like
Dan> trying to write an ftp daemon that can handle 5000
Dan> simultaneous clients in Java, but there are probably more
Dan> san
Anyone here interested in getting Java to handle heavy I/O nicely?
I'm personally interested in insane things like trying to write an ftp daemon
that can handle 5000 simultaneous clients in Java, but there are probably more sane
examples.
I have a few notes on the subject at
http://www.ke
On Mar 29, 2000, Ekkehard Kraemer wrote:
> Hallo John,
>
> JR>I'm thinking that the kernel TCP connection queues are filling up and
> JR>further requsts are getting dropped, but at 20?
>
> Did you check ulimit (file handles)?
>
> Did you try 'lsof | grep TCP'? Maybe it shows thousands of "
John Rousseau wrote:
>
> I'm doing some performance testing on our server and what I'm seeing
> is a little disappointing.
>
>
>
> I'm thinking that the kernel TCP connection queues are filling up
> and further requsts are getting dropped, but at 20?
&g
I'm doing some performance testing on our server and what I'm seeing
is a little disappointing.
We're running JDK1.2.2-RC4 (native threads) on several different
machines. I see almost identical behavior running on both of the
following machines:
quad 200MHz PII, 2GB memory, glib
Hallo John,
JR>I'm thinking that the kernel TCP connection queues are filling up and
JR>further requsts are getting dropped, but at 20?
Did you check ulimit (file handles)?
Did you try 'lsof | grep TCP'? Maybe it shows thousands of "zombie" TCP/IP
connections.
Which JDBC driver are you using
On Thursday Mar 30, 2000, Peter Schuller wrote:
> > Our application server starts rejecting TCP connections (actually,
> > the OS does, our app never sees these rejected requests) at about 20
> > simultaneous requests. The load average on the system runs a little
> > high (5-10) when requests st
. This takes particularly much time. Generally, the
> -->> same Java application (both AWT and Swing) performs very poorly under
> -->> JDK1.2 RC3. With jdk1.1.x performance is very good.
> -->
> -->Right. The JDK1.2 Graphics2D performance has lots of problems, one
e
-->> same Java application (both AWT and Swing) performs very poorly under
-->> JDK1.2 RC3. With jdk1.1.x performance is very good.
-->
-->Right. The JDK1.2 Graphics2D performance has lots of problems, one of
-->them being excessive numbers of repaints... especially when you dr
27; I meant a Java Frame (Window). So, eg. I have the main
> frame of my aplication an a dialog box. Moving dialog makes the main
> frame repaint itself. This takes particularly much time. Generally, the
> same Java application (both AWT and Swing) performs very poorly under
> JDK1.2
tion an a dialog box. Moving dialog makes the main
frame repaint itself. This takes particularly much time. Generally, the
same Java application (both AWT and Swing) performs very poorly under
JDK1.2 RC3. With jdk1.1.x performance is very good.
So the problem should not have
Marek Gmyrek wrote:
>
> I use the same system (RH6.1) with Blackdown JDK1.2 RC3 and have the same
> observations. Both native and green versions are very slowly, especially
> with GUI stuff, when compared to jdk1.1.8 (v1).
>
> Processor utilization is not so bad, until I move a window and a wind
On Thu, 20 Jan 2000, Marek Gmyrek wrote:
> observations. Both native and green versions are very slowly, especially
> with GUI stuff, when compared to jdk1.1.8 (v1).
>
> Processor utilization is not so bad, until I move a window and a window
> in background has to repaint itself. Repainting take
ork 15 times. Of these
That is ok. This is the result of thread implementation on Linux.
-->threads four or five of them just hammer the CPU, leaving the whole
-->machine at a crawl. Actual performance of our Java GUI isn't too bad, but
-->it's no where near where it should be.
Daniel Stux wrote:
>
> Hi folks,
>
> I've just installed two versions of the JDK1.2.2 for linux: Sun's RC2, and
> Blackdown's RC3. I am experiencing the wierdest behavior I have ever seen
> for a JDK.
>
I didn't see someone else mentioning this: did you try IBM's JDK?
/Oliver
--
5 times. Of these
> threads four or five of them just hammer the CPU, leaving the whole
> machine at a crawl. Actual performance of our Java GUI isn't too bad, but
> it's no where near where it should be.
>
> Switch to green threads. With Sun's JDK it's
in native threads is
> > absolutely crippling. There seems to be a serparate JDK process ID
> > for each running thread, or otherwise something is casuing it to
> > fork 15 times. Of these threads four or five of them just hammer the
> > CPU, leaving the whole machine at a crawl. Act
; thread, or otherwise something is casuing it to fork 15 times.
On Linux, threads have separate entries in the process table.
The Inprise JDK you're getting from Sun has a better JIT, which could
explain your green-threads performance differences. As for native
threading, the Sun/Inprise ver
; thread, or otherwise something is casuing it to fork 15 times. Of these
> threads four or five of them just hammer the CPU, leaving the whole
> machine at a crawl. Actual performance of our Java GUI isn't too bad, but
> it's no where near where it should be.
The thred model of L
asuing it to
> fork 15 times. Of these threads four or five of them just hammer the
> CPU, leaving the whole machine at a crawl. Actual performance of our
> Java GUI isn't too bad, but it's no where near where it should be.
You are seeing an artifact of the Linux threading model: nati
utely
crippling. There seems to be a serparate JDK process ID for each running
thread, or otherwise something is casuing it to fork 15 times. Of these
threads four or five of them just hammer the CPU, leaving the whole
machine at a crawl. Actual performance of our Java GUI isn't too bad, but
it&#
> Heap consumption and performance are real problems in Java.
But doesn't the JSL guarantee that an OutOfMemoryException is never thrown
until all non-reachable objects have been GC:ed? Why would the JVM though an
OutOfMemoryException without first doing a full GC?
--
/ Peter Schul
On Thu, 06 Jan 2000, Juergen Kreileder wrote:
> You should update your glibc first, the LinuxThreads library is still
> work in progress. E.g. the original glibc-2.1.2 release didn't pass
> sigcontext to user handlers, this was fixed in glibc-2.1.2 CVS tree as
> of 1999/10/24 (this is the versio
Hallo Michael,
MEM>that is good news.
MEM>i did alot of the same kind of testing.
MEM>i did "new Integer[100]"
MEM>and i never ran out of heap.
I did THAT one, too. I didn't run out of heap, too. But when using "new
Integer(0)" instead, it crashes - mind you, it doesn't run out of heap,
tho
> Michael E Moores writes:
Michael> ah, back to the same old problem. maybe i should get a phd in
Michael> compilers/linkers.
Michael> i suppose my best bet is to start by compiling everything
Michael> on the box with the same library path; including the jdk.
You should upda
ah, back to the same old problem. maybe i should get a phd in
compilers/linkers.
i suppose my best bet is to start by compiling everything
on the box with the same library path; including the jdk.
so when i dive into compiling the jdk when RC4 releases,
is the latest source available to do it?
that is good news.
i did alot of the same kind of testing.
i did "new Integer[100]"
and i never ran out of heap.
again, i want to look at what libraries your jdk is depending on.
i may have to point my cheap finger at glibc.
i have been using RC2/glibc1.2.1 cause my 3rd party
JNI interface cr
> Michael E Moores writes:
Michael> that is a valuable (non-political.. hee hee)
Michael> data point ekkehard.
Michael> so you must be using glibc2.1.2?
Michael> i am using mandrake 6.1, which uses glibc2.1.1,
Michael> so i have also been using JDK 1.2 RC2 to be compa
that is a valuable (non-political.. hee hee)
data point ekkehard.
so you must be using glibc2.1.2?
i am using mandrake 6.1, which uses glibc2.1.1,
so i have also been using JDK 1.2 RC2 to be compatible.
i wonder if glibc is causing some of the problesm?
i am also seeing some intermittent thre
heap space and performance
Hallo Edson Carlos Erickss,
some results for the Blackdown JDK 1.2.2 RC 3, native threads, sunwjit:
It does at least 80.000 loops without problems (I canceled it afterwards);
rt.free() is constantly 1048568 Bytes; the effective memory used by the
program is constantly
Hallo Edson Carlos Erickss,
some results for the Blackdown JDK 1.2.2 RC 3, native threads, sunwjit:
It does at least 80.000 loops without problems (I canceled it afterwards);
rt.free() is constantly 1048568 Bytes; the effective memory used by the
program is constantly 4520 K (+1024 K shared).
M
Hello Michael,
MEM>i think the jvm/jdk has a big leak with one or more of the
MEM>classes used.
I'm running the Blackdown JDK (1.2-RC3, with sunwjit and native threads) here
with very good results. I have only one (non-trivial) application running, and
it doesn't show your problem. It uses socke
FYI i am using native threads.
also, the garbage collection loop
ONLY tells the system we would like to encourage
a GC pass. i noticed that this DID make the
program have less periodic slowness..
At 08:40 PM 1/5/00 -0200, Edson Carlos Ericksson Richter wrote:
>For all: I'm doing a comparision b
E. Moores
>Sent: quarta-feira, 5 de janeiro de 2000 17:40
>To: Edson Carlos Ericksson Richter
>Cc: [EMAIL PROTECTED]
>Subject:RE: heap space and performance
>
>so you can also see the heap get used up
>with the win32 JDK?
>i don't see how the blackdown
For all: I'm doing a comparision based on report from Michael E. Moores using the same
program (see bellow) and anotating reports about memory usage (and, of course,
stability). Michael reported a crash after 45000 loops in Linux JDK1.2.2 ("linux 2.2,
blackdown 1.2 (glibc 1.2.1)").
My comparis
er
Cc: [EMAIL PROTECTED]
Subject:RE: heap space and performance
so you can also see the heap get used up
with the win32 JDK?
i don't see how the blackdown JDK can be used
for programs that persist for long periods.
i tried several versions of that code.
i agree you will al
C in Linux are not ok.
Edson Richter
--
From: Michael E. Moores
Sent: quarta-feira, 5 de janeiro de 2000 17:40
To: Edson Carlos Ericksson Richter
Cc: [EMAIL PROTECTED]
Subject:RE: heap space and performance
so you can also see the heap get used up
with the win32 JDK?
i
so you can also see the heap get used up
with the win32 JDK?
i don't see how the blackdown JDK can be used
for programs that persist for long periods.
i tried several versions of that code.
i agree you will always get a performance
benefit by NOT calling object contructors inside of a
Heap consumption and performance are real problems in Java.
But some great pratices in coding solve (or amenizes) the problem:
1) Don't repeat declaration of common used variables:
2) Create a thread in your main class taking a "forced garbage collection".
See the following pro
(default 16MB), and
my loop time was about 100 times every 6 seconds,
and the CPU was at 49%.
my questions are:
1. why does performance go down so much when the heap size goes up?
are we taking up lots of time sweeping through the heap?
2. why does the jvm max out the heap when
my
This is to announce the release of the Colt V1.0 Beta 4 distribution.
Check out the online documentation and/or download at
http://nicewww.cern.ch/~hoschek/colt/index.htm
Scope
=
The Colt distribution provides an open source infrastructure for
scalable scientific and technical computing in J
Hi, I guess the subject says all. Does clipping a large image to a
small clipping area improves performance of graphics drawing?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troubl
No--don't do that. DON'T convince yourself that
you need to avoid using a particular language feature "because of its
impact on performance". Use the language feature, profile the app, THEN
worry about performance. There are dozens of things you can do to bette
hi linux java fan
I want to know if the finally will affect the performace
of the program
I know that if the catch happen the program will affect the performance
,but I don't konw the finally will do what
Thanks
yours simple fan
[EMAIL PROTECTED] wrote:
>Things will improve -- they've already started to improve -- but not as
>fast as you'd like. The reality of the Linux revolution is that manning
>the barricades gives you the responsibility to help make things better
>and forfeits you the right to bitch and moan about the
Nick Lawson wrote:
>
> Paul Mclachlan wrote:
>
> > --- Nick Lawson <[EMAIL PROTECTED]> wrote:
> >
> > > I thought Swing was slow on Windows... I appreciate that JDK
> > > 1.2.2
> > > is still beta, but i'm having serious performance pro
Paul Mclachlan wrote:
> --- Nick Lawson <[EMAIL PROTECTED]> wrote:
>
> > I thought Swing was slow on Windows... I appreciate that JDK
> > 1.2.2
> > is still beta, but i'm having serious performance problems
> > with my
> > apps on linux, where I
Paul Mclachlan wrote:
> --- Nick Lawson <[EMAIL PROTECTED]> wrote:
>
> > I thought Swing was slow on Windows... I appreciate that JDK
> > 1.2.2
> > is still beta, but i'm having serious performance problems
> > with my
> > apps on linux, where I
--- Nick Lawson <[EMAIL PROTECTED]> wrote:
> I thought Swing was slow on Windows... I appreciate that JDK
> 1.2.2
> is still beta, but i'm having serious performance problems
> with my
> apps on linux, where I don't with the other os.
No, this is pretty much what
Hi,
I'm new to linux (but not java) so maybe I'm doing something
wrong and you guys can point me in the right direction.
I thought Swing was slow on Windows... I appreciate that JDK
1.2.2
is still beta, but i'm having serious performance problems
with my
apps on linux, where I
Is OpenSpot available for Linux? I have a server-side Java app that
needs to perform well and I would like to run it on Linux. It is a
console app with no graphics. Any suggestions would be greatly
appreciated ...
Andy
--
Well I have been using the jdk1.2v2 glibc2.1 version for about a day
now and have these observations. Things like the demo/applet/Java2Demo
run really slow. On the same system in windows using the win32 jdk1.2
I get about 30fps but in linux I get about 2fps.
Also twice the new jdk has caused
Hey,
I think splitting this file into more than one is a VERY good idea
to start with.
There is a programm called fastjar that is available from
freshmeat.net. I did not use it myself, but since it is written in good
old native C (or is it C++?) it MUCH more performant. I think y
bean. But for the performance part the
>applet is the big concern. Such a big jar, start off with big problems.
>
True, but I would argue that the actual performance of downloading the
entire jar onto the local VM each time the app starts is probably not that
big of a hit, and once it's ther
>> From the context of what you're saying, I'm guessing that you're running a
>> Java application and not an applet on the client. What I can suggest is
>> that you write a custom ClassLoader that uses java.net.URL to connect to a
>> given web server, check dates (against the .jar in your local pa
On Thu, May 06, 1999 at 10:27:41AM -0700, Ted Neward wrote:
> From the context of what you're saying, I'm guessing that you're running a
> Java application and not an applet on the client. What I can suggest is
> that you write a custom ClassLoader that uses java.net.URL to connect to a
> given we
for the performance part the
applet is the big concern. Such a big jar, start off with big problems.
Do you think the 1.1 security model will hamper a ClassLoader like that?
-Bob
On Thu, 6 May 1999, Ted Neward wrote:
> Robert--
>
> >Trying to optimize JAR performance. We hav
Robert--
>Trying to optimize JAR performance. We have a JAR that is 700K using
>JDK1.1.7 and are looking for ways to improve the performance when using
>it. At this time we cannot migrate to Java2 and utilize the
>JArURLConnection. Does anyone have any suggestions? We would li
Trying to optimize JAR performance. We have a JAR that is 700K using
JDK1.1.7 and are looking for ways to improve the performance when using
it. At this time we cannot migrate to Java2 and utilize the
JArURLConnection. Does anyone have any suggestions? We would like to
split the JAR into two
Peter Schuller wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > I have been comparing the performance of jdk 1.1.7v1a and 1.2pre-v1
> > and have found that 1.2pre-v1 is app. 60% slower than 1.1.7v1a with
> > native threads and TYA. I get the same dif
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I have been comparing the performance of jdk 1.1.7v1a and 1.2pre-v1
> and have found that 1.2pre-v1 is app. 60% slower than 1.1.7v1a with
> native threads and TYA. I get the same difference when I turn jit off
> and use green thre
Hi,
I have been comparing the performance of jdk 1.1.7v1a and 1.2pre-v1
and have found that 1.2pre-v1 is app. 60% slower than 1.1.7v1a with
native threads and TYA. I get the same difference when I turn
jit off
and use green threads. In all cases the CPU is 100% saturated
by
java. I'm ru
> Hi,
>
> Has anybody run any benchmarks comparing jdk117 with tya vs jdk1.2 with
> sunwjit?
> My runs so far (console applications with timing), indicate that
> ***jdk1.1.7+tya1.2 is at least two times faster than jdk1.2-pre1!!!***
> This behavior is for computationally intensive procedures, I d
> I am developing a network performance benchmarking program with java. I
>have resently intalled jdk1.1.7 in my redhat5.1but i am getting very slow
>prefrormance. i.e. a for loop from 0 to 3x10^7 takes about 10 secs while
>when using vcafe in windows95 itneeds about 1 sec on the sam
[EMAIL PROTECTED] wrote:
> I am developing a network performance benchmarking program with java. I
> have resently intalled jdk1.1.7 in my redhat5.1but i am getting very slow
> prefrormance. i.e. a for loop from 0 to 3x10^7 takes about 10 secs while
> when using vcafe in windo
1 - 100 of 134 matches
Mail list logo
