Why Does LimeWire Seem To Run More Slowly?
 

The answer to this question requires a bit of background in Java, which is the language that LimeWire is written in...

Java programs run in what's called a "Java Virtual Machine" (JVM). The JVM reads the code that makes up LimeWire and tells your computer what to do. This means that LimeWire (and all Java programs) can be run on any operating system that has a JVM.

One of the recent additions to JVMs is what's called a "Just-In-Time Compiler" (JIT). This is something that, while running a program, optimizes and converts the java bytecode into native machine code. The addition technically came when Java 1.2 was introduced, but a JIT was backported by Symantec to Apple for Java 1.1.8 on Mac Classics.

Unfortunately, this JIT becomes very buggy as the language is pushed to its limits. It was causing many problems that destabilized LimeWire and caused errors that are generally impossible. Prior to the release of 3.6.15, the JIT was stopping LimeWire from even starting. (Instead, a message popped up saying there was a bug in the JIT and that Symantec should be notified.) Thus, in order to keep LimeWire running, we had to disable the JIT on Mac Classic.

The result of this is that LimeWire runs slower, because the JVM is constantly converting the java bytecode into machine code instead of remembering and optimizing it.

We'll look into determining if it's possible to turn the JIT back on, but it is going to be difficult to do.

Thanks.

You can attempt to speed up LimeWire by enabling the JIT yourself. This can be done by opening up the file "LimeWire.lax" in any text editor. (LimeWire.lax can be found in the same folder that the LimeWire program is in.) Look for the line that reads:
lax.nl.macos.java.compiler=off
and insert a '#' before it, so it reads:
#lax.nl.macos.java.compiler=off

Then save the file and start up LimeWire.

I cannot guarantee that LimeWire will continue to work. But if it does, it will be a little faster.

Don´t forget to make a copy first or write the default settings down before changing it!!!

I am not sure if this effort has such a great effect. Its not a big program which is really needed to speed up... but this is only my opinion.

Morgwen

P.S.:

An other solution would be to rewrite it in C++... I am kidding now. :p

It has an effect, Morgwen. The large number of complaints about the speed of LimeWire 3.6.15 is because it is the first released version that we disabled the JIT for Mac Classics.

I personally see a huge difference in file verification times (even running in Classic environment on a souped up powerbook) with the JIT turned on vs off.

After I read your first post more carefully I see what you mean. :cool:

Ignore my statement. :)

Morgwen

Re: Why Does LimeWire Seem To Run More Slowly?
 

You can attempt to speed up LimeWire by enabling the JIT yourself. This can be done by opening up the file "LimeWire.lax" in any text editor. (LimeWire.lax can be found in the same folder that the LimeWire program is in.) Look for the line that reads:
lax.nl.macos.java.compiler=off
and insert a '#' before it, so it reads:
#lax.nl.macos.java.compiler=off

Then save the file and start up LimeWire.

I cannot guarantee that LimeWire will continue to work. But if it does, it will be a little faster. "You sir, are an absolute genius. I tried the above suggestion, it took about 15 seconds to do, and it works perfectly. Now my filesharing works perfectly, file verification and saving are much faster, and the whole program is more responsive. In my 8 or so years of using computers I have never seen anything that created such an improvement with so little effort. Thanks a lot. "

Well i put the # into the LimeWire.lax as suggested on my 7500 machine under OS9.2.2 and guess what? It's a hell of a lot better, button respond quicker, still room for improvement, the verifying is speedy, sticks at certain stages, then zooms up and done in just a few :)

sberlin: THANK YOU for your explanation and instructions to reenable the JIT! I hadn't been suffering the failure-to-start problem, so ever since the JIT was disabled by default, Limewire's hashing thread -- and by extension Limewire itself -- had become almost completely useless (several hours to hash a 40-megabyte file, and no, that's not an exaggeration.)

Reenabling the JIT hashed that 40-megabyte file in less than a minute. I'm on a 233 MHz G3 Powerbook, with 384 MB of ram.

I think the JIT is more valuable on old machines than you believe it is! :) Limewire is usable again. Thank you!

mm just wundering when the prob whith the code hapens becuse it must to have bean a big prob or it wudent have bean ternd off just wunderd befor i try it dose the prob only start after a whyel or strat away or when:p

I'd answer your question, sleepey, but I'm afraid I only understand English.

This isn´t really a problem. Java is runnning slower than other languages like C++, sberlin suggested how to increase the speed of it.

He wants to know when this problem starts and if this happens always.

Morgwen

I don't have that information in .lax
 

Hello.

I'm using Limewire 3.4.5 on an iMac 233. I located the limewire.lax text document, but cannot locate the line you mentioned in order to make the suggeted modification. The text I located begins with "# LaunchAnywhere (tm) Executable Properties File - Zero G Software, Inc."

Are you referring to a different version of Limewire, or am I doing something wrong?

Thanks.

Download 3.8.5. I _think_ we let the JIT on again in that release.

Slow running
 

I downloaded the newer version, as you suggested, and made the recommended change to the .lax file. It then took 3 minutes to open the 3.8.6 version of the program. Is that normal?

I am running 0S 9.2 on a 233 iMac.
Thanks.

I'm using the new LW 4.0.3 on Mac OS 9.2.2, tell me where to look for the line to change lax.nl.macos.java.compiler=off to #lax.nl.macos.java.compiler=off, I can't find it, even with a word search. And my downloads are slow as molasses on this.

This is my limewire.lax file.

# LaunchAnywhere (tm) Executable Properties File - Zero G Software, Inc.

# LAX.APPLICATION.NAME
# --------------------
# the default name of this executable -- do not edit

lax.application.name=LimeWire


# LAX.CLASS.PATH
# --------------
# the Java classpath necessary to run this application
# Can be separated by colons (Mac OS/Unix) or semicolons (Windows)

lax.class.path=MessagesBundles.jar:jl011.jar:swing .jar:xerces.jar:LimeWire.jar:logicrypto.jar:collec tions.jar:themes.jar:ProgressTabs.jar:mp3sp14.jar: icu4j.jar:i18n.jar:commons-logging.jar:commons-httpclient.jar:id3v2.jar:lax.jar


# LAX.COMMAND.LINE.ARGS
# ---------------------
# what will be passed to the main method -- be sure to quote arguments with spaces in them

lax.command.line.args=$CMD_LINE_ARGUMENTS$


# LAX.DIR
# -------
# path to directory holding LaunchAnywhere's native launcher

lax.dir=/Macintosh HD/Applications (Mac OS 9)/LimeWire/


# LAX.MAIN.CLASS
# --------------
# the class that contains the main method for the application

lax.main.class=com.limegroup.gnutella.gui.Main


# LAX.MAIN.METHOD
# ---------------
# the method in the main class that will be invoked

lax.main.method=main


# LAX.NL.CURRENT.VM
# -----------------
# the VM to use for the next launch

lax.nl.current.vm=


# LAX.NL.JAVA.LAUNCHER.MAIN.CLASS
# -------------------------------
# main class of LaunchAnywhere's java launcher -- do not adjust

lax.nl.java.launcher.main.class=com.zerog.lax.LAX


# LAX.NL.JAVA.LAUNCHER.MAIN.METHOD
# --------------------------------
# main method of LaunchAnywhere's java launcher -- do not adjust

lax.nl.java.launcher.main.method=main


# LAX.NL.JAVA.OPTION.ADDITIONAL
# -----------------------------
# Java command-line arguments added verbatim to the command line.

lax.nl.java.option.additional=-Dorg.apache.commons.logging.Log=org.apache.commons .logging.impl.NoOpLog -Djava.endorsed.dirs=



lax.nl.java.option.java.heap.size.initial=20000000



lax.nl.java.option.java.heap.size.max=120000000


# LAX.NL.JAVA.OPTION.JAVA.STACK.SIZE.MAX
# --------------------------------------
# Set the Java stack size to 64K

lax.nl.java.option.java.stack.size.max=65536


# LAX.NL.VALID.VM.LIST
# --------------------
# a string containing one or more of [ ALL JDK JRE J1 J2 JRE_J1 JDK_J1 JRE_J2 JDK_J2 MSJ MRJ ]
# delimited by spaces or commas. If the native launcher cannot find the current vm,
# it will search for ones in this list

lax.nl.valid.vm.list=JRE_J2 JDK_J2 MRJ


# LAX.NL.WIN32.MICROSOFTVM.MIN.VERSION
# ------------------------------------
# The minimum version of Microsoft's VM this application will run against

lax.nl.win32.microsoftvm.min.version=2750


# LAX.ROOT.INSTALL.DIR
# --------------------
# path to the installdir magic folder

lax.root.install.dir=/Macintosh HD/Applications (Mac OS 9)/LimeWire


# LAX.STDERR.REDIRECT
# -------------------
# leave blank for no input, "console" to read from the console window,
# and any path to a file to read from that file

lax.stderr.redirect=err.txt


# LAX.STDIN.REDIRECT
# ------------------
# leave blank for no input, "console" to read from the console window,
# and any path to a file to read from that file

lax.stdin.redirect=


# LAX.STDOUT.REDIRECT
# -------------------
# leave blank for no input, "console" to read from the console window,
# and any path to a file to read from that file

lax.stdout.redirect=out.txt


# LAX.USER.DIR
# ------------
# left blank, this property will cause the native launcher to not
# alter the platform default behavior for setting the user dir.
# To override this you may set this property to a relative or absolute path.
# Relative paths are relative to the launcher.

lax.user.dir=.


# LAX.VERSION
# -----------
# version of LaunchAnywhere that created this properties file

lax.version=5.0

zzz
 

Zzzzhuh?!

Oh... I just downloaded the newest version of Limwire Pro, wich is 4.0.2. for the OS.x. nice touch putting in the message about freezing the classic version at 4.0 AFTER paying, especially since that annoying pop-up tells me I can get a newer version...

I could swear i had 4.0.7 before, I'm not sure, but that kinda sucks.

Anyways, I cant find that line of code where I'm supposed to put in the "#" to fix the JIT problem. Do I have to download an older version?

I'm really pleased to have paid another 18 bucks for a useless 30 seconds laggin' limewire. Woohoo!

Angry Xmas Gnome

slow slow running
 

I definitely agree with Rent-A-Ninja: just downloaded Limewire Pro 4.5 is running on a G4, 450 Mhz, with 640 Mb Ram... (MacOs 9.2.2) and it is so slow...!
I can't find that line of code where I'm supposed to put in the "#" to fix the JIT problem in the LimeWire.lax document.
Can someone help???

Umm ... I think you'll find it somewhere in the thread called 'For those who can't connect' in the connections section. It's 37 pages long but I'm sure it's within the 1st 25 pages somewhere. that's the last place I can remember seeing it. Have a look from p1 anyway. You might pick up some hints! ;)

Quote:
Have a look from p1 anyway. You might pick up some hints!
----------
What do you mean with p1???
Anyway thanks!

so so slow... (part 2)
 

Hi, can somebody understand what's going on???
As I said in a previous post I bought LW Pro 4 (no 4.5) for Mac Os 9, and it was extremely slow.
As you suggested I started reading the forum on connections - where I lost myself, but found the tip to get faster response from the software (declicking auto connect at startup). The first time it got really better, but a second time never happened again... The software got stuck up at "Connecting..." for hours...
After several days, several other installations - always without success - today I tried to remove everything from my hard disk, and download again LW BASIC, and it works!!!

In the meantime I found that in LW Pro:
1. the uninstaller actually leaves some files on the hard disk
2. the file err.txt says what follows, maybe it is of some interest for you:
----
Exception occurred during event dispatching:
java.lang.NoClassDefFoundError: com/limegroup/gnutella/settings/StartupSettings
at com.limegroup.gnutella.gui.TipOfTheDayMediator.con structDialog(TipOfTheDayMediator.java:392)
at com.limegroup.gnutella.gui.TipOfTheDayMediator.<in it>(TipOfTheDayMediator.java:167)
at com.limegroup.gnutella.gui.TipOfTheDayMediator.ins tance(TipOfTheDayMediator.java:177)
at com.limegroup.gnutella.gui.GUIMediator.closeStartu pDialogs(GUIMediator.java:355)
at com.limegroup.gnutella.gui.GUIMediator.showInterna lError(GUIMediator.java:1759)
at com.limegroup.gnutella.gui.ErrorHandler$Error.run( ErrorHandler.java:70)
at javax.swing.SystemEventQueueUtilities.processRunna bleEvent(Compiled Code)
at javax.swing.SystemEventQueueUtilities$RunnableTarg et.processEvent(Compiled Code)
at java.awt.Component.dispatchEventImpl(Compiled Code)
at java.awt.Component.dispatchEvent(Compiled Code)
at java.awt.EventDispatchThread.run(EventDispatchThre ad.java)
-----
And now... good night!
p

i have a brand new mac book pro 15,,,i loaded lime wire pro and tried to download a song to listen to,,,just one song ,,,,its been over an hr and its only halfway done,,,any way to speed this up??? i dont ever remember it being this slow when i had a regular desktop

Nothing to do with the computer or program, I'd suggest it's slow upload speed from the uploader. They may be using dial up connection, else don't have much upload bandwidth & have several people alongside you uploading their files. Difficult to say. But let us know if this happens with any other downloads. :)

The download speed is nothing to do with the program as this thread topic refers to. Sometimes LW runs slowly on a computer with little ram or older slower internal computer technology which gives LW that laggy effect. Older Java was not super efficient either, especially Apple's java versions.