I am running steam on a mac and thinking about attempting some of these things, but I still have no idea which files to manipulate on the OS x operating system and where they live. Does anybody have any suggestions where to start?

I agree. If someone could give direct instructions on how to increase performance via steam on a 32-bit OS, it'd be greatly appreciated. I took a good long look over this thread to figure it out myself, but all I get a sense of is that I need to change something in the launch options and change something java-related. I already have JDK downloaded for whatever part that is needed in. But when it comes to everything else, I just can't piece it all together.

yeah, that would be great!

By the way, if you prefer running spiral knights in high priority and use non-steam version but have the game installed, you can stick this into the "Target" to automatically boot it in high priority. No one mentioned that in this thread, so thought I'd add it.

C:\Windows\System32\cmd.exe /c start "runhigh" /high

you stick it before everything else.. change the cmd.exe directory to where it is in your windows install on your computer and should work fine.

Tweaking tutorials.

Do it at your own risk, comes with no warranties whatsoever. (Your PC may blow up, dogs may die and Vanaduke may maul you on your next run, etc etc.)

Can someone summarize what is relevant for this java tweak?
I have windows 7 64-bit non-steam.

So far, I have re-targeted the java to run the 64-bit. Starting it up like this already seemed faster. I will monitor how things go. So far I noticed that when I switch between a DA & GF, the colour of the previous sword remains and you get a weird orangy blade. Menu's load with a slight lag at first, but then almost instantly after the 2nd or 3rd time.

I also did the tweaks up to point 6 in the OP.
6. Change the way the java garbage collector works and minimize the small random lockups the game had while playing (incremental garbage collector).
"C:\Program Files\Java\jre6\bin\javaw.exe" -server -Xincgc -Xms1024m -Xmx2048m -jar getdown-pro.jar .

I didn't think the stuff after that was needed. I also had no idea what it did.
I also read the rest of the thread and was thoroughly confused.

I am using Windows 7 steam, changed over java to 64 bit as needed per the directions, and then added the command parameters in Launch Options as such:

-server -Xms1g -Xmx3g -Xms1024m -Xmx2048m

Is this about correct? Should it look differently? If so, how should it look?

Java doesn't seem to recognize the -Xms parameters, at least on Java 7 64-bit. You'll know when you launch the game and check the chat logs.

I redirected Spiral Knights's launch of Java by using symbolic link to Java 7 64-bit I already installed on another folder. The advantage experienced was gaining twice the framerate and a working surround sound audio.

The disadvantage is that Java 64-bit doesn't launch without disabling Steam Overlay first.

Freeze lag still happen as usual, but it seems to be a shorter lag time.

Agree with the part that the culprit of the whole stuttering on Steam is due to our inability to weak JVM properly (thanks to little file called getdown).

Can OOO actually look into this and at least revise the setting in getdown, so that Steam users can have the Xms and Xmx parameters set to something more suitable for modern hardware please?

I'm a steam user and have been working with the information in this threat to improve performance. OOO really should put some of these things in the in-game configuration options or otherwise make them less obtuse, the default settings are great for low-end computers but shouldn't restrict everyone to that level of performance.

Alternately, they could provide a method of uncoupling steam accounts, so we can log in from the standalone client without using Steam. Getting these tweaks to work when launching SK directly seems to be much easier.

@Renpartycat

Source games on Steam have a built in defrag feature. It is crazy fast to do. Source is long in the tooth, but it is a very sold engine that I would take over java any day.

The -server option probably has the greatest effect, though it depends on the overall complexity of the game's code. It sets a bunch of the JVM's options to higher performance presets typically required of server applications. The tradeoff is slightly higher startup and load times and more memory usage. The 64-bit JVM enables this option by default so we get an extra parameter to work with when using it.

I did not agree with the suggestion to use the -Xmx option the first time this topic was discussed. It's obvious that the game already uses more than the 256M requested by the default launcher. Even with that, the stalls that occurred usually took over an hour to start for me. I used (badly, I guess) the example of firefox 2 to point out that a program allocating a lot of memory on a system with a lot of memory does not mean that the program is performing well. In the case of firefox 2, this is due to various memory leaks. This is not the case with Spiral Knights. If the game actually contained memory leaks, we would be experiencing total crashes not intermittent stalls.

The stalls are caused by the very mechanism that prevents the game from having memory leaks, the garbage collector (GC). In very simple terms, the GC allows programmers to manipulate data without worrying about how much memory it'll use by allocating and freeing memory automatically. It works similar to real life garbage collectors who pick up your trash once a week, saving you a trip to the dump.

By default the JVM uses a GC that minimizes processor usage by waiting to do all the garbage collection at specified times. The GC does not cause the main program to slow down while it is not collecting, however when it comes time to collect any unused objects, it must take full control of the processor. The game stalls we experience are due to these "stop-the-world" events. The -xincgc option that was suggested three months ago alleviates the stall time by breaking up the GC process into smaller chunks. The GC will incrementally check if memory is ready to be cleaned in smaller steps during which it siezes full control, but for shorter periods of time compared to the default GC. There may still be noticeable stalls depending on the size of total memory when using the incremental GC.

The second option, -XX:+UseConcMarkSweepGC, uses a different strategy to collect garbage. The concurrent mark-and-sweep (CMS) GC will constantly check what parts of memory are being used while the main program is running. The CMS uses more processing power than the default and incremental GC but it doesn't require any prolonged stop in execution. There are two necessary pauses, but they are brief. Essentially, the CMS requires that no memory is modified while it checks object usage (marking) or deletes unused memory (sweeping) so it will pause the main program execution during these phases. -XX:+CMSIncrementalMode further optimizes the CMS by breaking up the marking and sweeping steps in a similar fashion to the improvements brought by the incremental GC to the default GC.

-XX:+ExplicitGCInvokesConcurrent is marginally useful in case one of OOO Tree Rings' developers decided to explicitly call for GC at some point in the game's code. Normally, an explicit call to the GC would use the default GC strategy. As you may have guessed, this option will use the CMS instead to reduce the stall time, even if the total time to clear the memory is longer.

Finally, we return to my objection to -Xmx. Typically, a larger memory size increases each stall time. Using more memory may delay the time until the first garbage collection, but it increases the length of the stop-the-world event by about twice the increase in memory in the default GC and by about 1/6 with the CMS. Increasing memory size from 256M to 1024M extends the stall by 8 times with default GC and 4/3 times with CMS.

I didn't do any digging to find exactly how steam passes launch options to the launcher to make it pass them forward to the game. Simply adding extra command line flags to the launcher shortcut does not work. I'm sorry I can't help any more with that part.

I can clarify the 3 recommended options for 64-bit users though:
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+ExplicitGCInvokesConcurrent

I've figured out how steam passes arguments through the launcher to the game. In the process of discovering this, I finally realized something I should have noticed 4 days ago. The order of the arguments in launcher.log when setting launch options in steam imply that the launch options are parameters for the game, not the JVM. This explains why I couldn't profile the GC. I don't even feel like sharing the parameter passing syntax now.

So as it stands, making a custom launcher script is the only way to tweak the JVM's performance and steam users are reconfirmed to be untweakable.

Maybe someone else can do something useful with this information.

You can use the following syntax to make the non-Steam launcher pass arguments to the game the same way Steam does:
java -jar getdown-pro.jar . client arg0 arg1 arg2

So using Sypsy's example in #60 of this thread, you would have:
"C:\Program Files\Java\jre6\bin\javaw.exe" -jar getdown-pro.jar . client -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+ExplicitGCInvokesConcurrent

This gives the same result as running the Steam version with the launch options set to -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+ExplicitGCInvokesConcurrent

Of course, as I already mentioned, this doesn't actually pass the arguments to the game's JVM but to the game itself. The game does nothing useful with JVM arguments passed to it in this way.

The current setting for Steam SK is not optimal. Please tweak it for us and patch that getdown file please?

Yeah, tried out the one you had in post #80, but didn't seem to do the trick for me. Trying #81 as well.

I'm on Windows 7 x64, Steam SK and Java 32 Bit. I get some good results by using "-Xmx1g -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+ExplicitGCInvokesConcurrent". If people wonder how I did this, I wrote a little stub program in C to replace javaw.exe, so it would pass the required parameters into JVM (instead of passing it into SK). Everything else is unchanged (including the Steam login process). Graphic is set to maximum and running at 1080p.

The incremental garbage collector (GC) definitely works better under Steam. Before the switch, my SK would lag after an hour sitting in town. Yesterday I managed to cruise around Haven, Bazaar and Arcade for hours without needing to relog. I have tested it in Roar and JK levels. There were still a few pauses (about 3 hiccups for whole night of gameplay) but I managed without any relog for the whole night.

The drawback of this tweak seems to be that SK takes longer to load maps. I think this is a fair trade off. It's much better than stuttering every 5 steps when you are fighting in Clockworks.

Profiling results suggest that SK uses roughly 450-500MB of memory at peaks. So I'm more inclined to support the view that more memory doesn't necessary mean better performance. But we definitely need more than 256MB on Steam SK (which is the default setting on Steam SK). Also, due to the current configuration in Steam SK, the maximum memory I can assign is 1GB. (JVM won't start if I assign more as it seems to conflict with the default setting OOO provided.)

In conclusion, I strongly suggest OOO to take a look at this tweaking option for Steam users. Evidences tend to support that the stuttering on Steam SK is due to inappropriate tweaking of JVM. The default GC seems to be the culprit.

Hey guys, I just linked to my /jre7 folder directly, calling the link java_vm. This way, Java will stay updated etc etc. Seems to work fine. I'm on win7, but the instructions are the same:

http://www.howtogeek.com/howto/windows-vista/using-symlinks-in-windows-v...

C:\Program Files (x86)\Steam\steamapps\common\spiral knights>mklink /J "C:\Progr
am Files (x86)\Steam\steamapps\common\spiral knights\java_vm" "C:\Program Files\
Java\jre7"
Junction created for C:\Program Files (x86)\Steam\steamapps\common\spiral knight
s\java_vm <<===>> C:\Program Files\Java\jre7


I thought about just copy-and-pasting the source code (in C) to this thread. Thing is that I read the forum rules and this could be in violation of the rules relating to exploit. So I rather not risk it because I do not want to get banned. (The forum rules do not prevent me to discuss results that I discovered on my own.)

Use this code to locate the source: 66y5bt5. Good luck compiling and let us know of your results. For people who are on Mac, this may work also as long as you get it compiled.

It's not that bad to code it yourself. I spent about an afternoon to get it working. Half of the time went to figuring out why SK complains about multiple instances running. >.>

Alternatively, you can use a batch file compiler as suggested by another poster earlier. I didn't go for this solution because I do not know which batch file compiler is safe and it's very easy to get a keylogger (or other malwares) attached if you just randomly pick one off the Web. So I decided to write the stub myself. This way I know what can go wrong and where to look.

You're a geek if you created directory junction to redirect Spiral Knights's JRE to an updated JRE in your Program Files.

I've been having smooth frame rates for a week now since I used Java x64 on Spiral Knights. Of course I've used directory junction before to split Steam game folders between physical hard drives.

Some interesting results:

• went through FSC tonight with a 4 people party. I only experienced a 1 second pause for the whole trip. The Core did not lag. I'm using an Intel Core 2 Duo E8500 CPU and two Geforce GTX 460 (but only one GPU got used by SK);
• a guildmate of mine who went on the same trip above, using the same tool, reported slightly more pauses (about 3 according to my recollection). The Core did not lag. He is using an Intel Core 2 Quad 2600 CPU and a Geforce 8600 GT.

I'm suspecting the incremental collector uses more CPU cycles. And since SK does not appear to support quad core, the core speed matters more than number of cores.

Also, I do not think the -Xmx flag does anything useful in my case, because it gets overridden by OOO's default setting (which initializes the maximum heap memory to 256MB).

For us non-coders (I only know HTML, CSS and some XML), could you post a tutorial on how to go about modding the javaw.exe file to get the three XX parameters to work? And if not possible here, maybe from your Steam page? Please?? Honestly, I would love to have less stutters and pauses in this game, as a lot of the time, they can be death.