experimental Possible Performance Increase

[Keenan 5,539]

This information is outdated and no longer recommended. This post will be locked.

 

 

Spoiler

 

EDIT

So fixes found over the weekend were pushed to the unstable client as indicated here: 

This does not include the GC tweak I mentioned below, and I strongly encourage everyone to try it without any modifications first.

 

--- Keenan

 

---

So as some of you may know, I've been doing work on trying to resolve the client issues that have cropped up since the latest update. I am still working on this, but in my investigating I have uncovered a few changes you can make right now to help with your performance. These are experimental, but I would appreciate feedback.

 

A few things first:

• Results may vary. If you have a very old CPU, this may degrade your performance. I would appreciate anyone with a single-core CPU to comment though, let me know if you try it and how it worked for you.
• The memory I specify works well for me, but you can change it to fit your needs. Less than 2048m may find performance issues, but greater should not affect things very much.
• This is an advanced and experimental setting. You will need to know where your Java JRE is installed (where javaws.exe is) and be okay with either making a custom shortcut or running this from Start > Run or CMD.EXE
• This has only been tested on Windows so far, so Linux/Mac users please chime in.

 

Step 1

Run this:

"C:\Program Files\Java\jre1.8.0_73\bin\Javaws.exe" -J-Xmx2048m -J-XX:+UseConcMarkSweepGC http://www.wurmonline.com/client/wurmclient_unstable.jnlp

Notes:

• You will need to change the jre1.8.0_XX to whatever version you are using, but I highly recommend using the latest.
• You can find the latest offline installer for Windows 64-bit here: http://javadl.oracle.com/webapps/download/AutoDL?BundleId=116030
• If you are not using 64-bit Java yet, I strongly recommend that you do. You will have issues with a higher heap space (the -Xmx2048m) on 32-bit Java.
• Do change the 2048m to something that makes sense for your system. If you only have 2GB of RAM, you should only do 1024m. (And this tweak may not work well for you, but again - please comment!)

 

Step 2

When you start up, click Settings, then go to Advanced Graphics, and look for Model Loading Threads. Try changing this to 2 or 3. I am using 2 at the moment.

 

What is this doing?

The model loading threads I have found to be somewhat taxing on the CPU, and the default 5 was causing my CPU to be running quite high and freeze when loading a large local of players or many buildings. This can also happen if you stand in one place for a long time and then move. You want at least 2 threads, as one will be used for the older models and one for the newer WOM modes. Try 3 threads total, which will give you 2 for the newer models. If you find it gets more choppy, dial it back to 2. This is something I plan to look into this weekend, so this should be considered a temporary fix. Ideally we do want more model loading threads for a faster load time.

 

The -Xmx2048m is telling Java to use a maximum of 2GB of RAM. On max settings, in and out of a fairly decent local of players, I never used higher than 1.6GB. Your results may vary, but keep in mind that if you exceed this number you will have an OutOfMemory exception and your client will crash. So setting it to 1024m and running on high resolution textures and high graphic settings would not be advisable.

 

The -XX:+UseConcMarkSweepGC tells Java to use a different scheme for garbage collecting than normal. I did quite a bit of research into advanced topics regarding Java and memory, and found that this scheme is great for programs where you need fast response time. To explain in more detail, Java has two main pools of memory: Old and New. Everything starts in New, and if it's found to be needed for a while, it gets moved to Old. Garbage collection is when Java takes a look at it's memory and determines what bits it doesn't need anymore. The New section is done more frequently than the Old, but the Old section takes considerably longer to clean. The problem is that every time Java does this, it forces the program to stop whatever it's doing until it finishes, thus causing the famous "travel lag" or "jitters". This is also why people raising the -Xmx to very high amounts would stop travel lag from being a problem, for a time.

 

What Concurrent Mark Sweeping does is it does smaller collections more frequently, and it does this for threads in a much more efficient way. Since Wurm is multi-threaded, meaning it has helper programs running in the background, this is a good performance increase.

 

My observations

By making both changes, I went from using 60-90% of my CPU and running dangerously close to maximum heap space to using 20-50%, with the occasional spike if I'm loading a large number of models. The spike would not last long, and is more like the old hiccups we're used to when running through largely developed areas. This was all with a fairly large sermon group (15 players) in my local, along with many structures and trees. With 2048m heap, my memory usage would go anywhere from 1.4GB to 1.6GB, with maximum settings (shadows off). I've been in-game for 2 hours, and have traveled a fair distance and returned to this heavy local more than once. (For a point of reference, I was at Odynn's place on Deliverance as Bugslayer)

 

I had others that helped me test this report a jump in performance as well as a reduction to near elimination of travel lag, but I'm trying to be conservative until more people are able to test.

 

Send me a forum PM if you have questions, though answers will wait until morning (US Eastern) as it's about 3am my time and I'm exhausted!

 

Happy Wurming!

 

 

[Tinkerer 107]

Oh... this sounds like great news. Nice work Keenan, I will certainly be trying it and will let you know if things improve.

 

 

EDIT: Instantly seem to notice that rotating and moving the camera is much smoother. Before it was often quite jerky and often locked up for a second or two.

 

I cant believe how much of a difference I can feel.. my laptop keyboard is also not so hot (after playing for many hours) and switching to the unstable client. My mouse movement feels so much smoother.

 

Before when standing still for a while mixing mortar or some other repetitive task and then rotating the view to find my cart (or similar) my screen would often lock up and would briefly be incredibly laggy and jerky. That seems to have gone (or been drastically reduced). I can now spin around and do 360's. Before, it was usually too jerky. The onscreen FPS is about the same as before (possibly slightly higher), but when it would 'lock up' briefly - things like FPS also didn't update and display correctly anyway.

 

Still awaiting other local players to come online so I can test with other players around, but so far, everything is excellent. THANK YOU!

Edited February 27, 2016 by Tinkerer

[icbash 352]

ill test morrow when i get on looks like it should work

[Moth 12]

I noticed some improvement, but after travelling I still got lag and stuttering once anyone appeared in local.

[KaiH 1,126]

i am surprised how good this

-XX:+UseConcMarkSweepGC

option works for me

 

EDIT: well, at least for 30min. then jp2launcher.exe took 90% CPU usage on avg. (running around a lot, including looking at Odynns sermon place), idleing for 5min got CPU usuage down to 40% avg., but moving then got me right back to 95% avg.

 

i'll check other model loading threads settings. this run was set to 4

 

EDIT2: tried other model loading thread numbers and best for me is 3, model loader thread priority 'normal'; but still after 30min there are "hangers" where CPU usage peeks up when moving.

 

overall: memory usage still increases over time (i never had above 1.67gb used), but by far better than before. the best result of this is the lowered CPU usage.

now we only need a "flush memory" for java when it starts hanging after 30min.

Edited February 27, 2016 by KaiH
after 30min.

[Propheteer 7,139]

works very well for me, thanks a bunch!

[Kegan 3,926]

I don't have any problems but i think you can set that -Xmx2048m thing in the java runtime parameters in the java tab on the control panel. (there used to be a post about it in the help section but it might have been archived by now) 

 

I found the post so will link it here..

[Keenan 5,539]

You can set it in options, but I avoided that as this will set it for ALL Java applications! Being that I was trying to get feedback, I didn't want people winding up with options set that may not actually work as intended.

 

I also want to reiterate that this is NOT a "fix". It's something I discovered while digging deeper into how Java works with memory, and I noticed improvements and wanted to share. I have a nice long weekend of coffee and debugging ahead of me still!

[Wurmhole 3,650]

I am using these settings now.  It is an improvement, but I just made a trip from the south end of Pristine to the north and by the time I hit north, I was at 1988 RAM and getting the sticky travel mode, like old days.  Run 10 tiles, pause, run 10 more, etc.  I've relogged and am making my way home now.

[Jaz 2,666]

I've changed the launcher settings to the above, model loading threads 2. My system is Core2 Quad Core, NVidia GT640 graphics card 2/ 2GB RAM, 8GB system RAM.

First day experiences with heavy load (treasure hunt on Celebration):

 

* upon client start models load very fast

* displayed FPS is around the same as before

* it feels that dense/big structures cause smaller FPS drop

* very serious lag, client freeze and FPS down to 0 when there are 10+ players in local (not in view, just local). Tried to relog with very low graph settings, still bad but at least could turn and moor my knarr.

* travel lag is still significantly worse than before the recent updates, following the treasure hunt track I had to relog 7-8 times during the 4-5 hours I've been riding (usually no or just 2-3 characters in local). All travel was done on very low graph settings, my usual higher ones caused travel lag much sooner.

* CPU load on any of the 4 cores did not exceed 60-70% even when movement got stopped in the client, usually CPU load is 30-35% max.

* client used up to 2.1GB RAM (with heap set to 2048, without setting it the client was not using more than 1.6GB),

 

I have tried to wait 1-2 mins to the client freezes to clear up hoping that garbage collection will do its job but no success, only resolution is to relog.

Happened 2-3 times during the day that in the middle of riding character fell from the horse (maybe a new riding skill is introduced in the background? ). This can be quite deadly riding on steeper hillsides.

 

I changed the heap to 4096 now, will feedback on it when I had some travel with it.

[newman330 72]

I tried 2 things this weekend.

 

First thing i did was reset windows 10.  This was recommended by someone after Retrograde asked folks to submit there post graphics issues in one of the threads posted a couple days back.

This did nothing for me except keep me busy reinstalling all sorts of useful stuff.  Problems remained

 

Second thing i did was try Keenan's suggestion above.  Well..  I'd say some things changed, mainly i didnt experience lag in our common area while we were sermoning.  Actually, things looked pretty good for an hour or so and then things degenerated again.  I had no problem tabbing across to different toons... they were not 'disconnected' like they had been previously when they took a minute or so to fully engage.  Response was good.  The problem was toon started dropping out...  leaving world.  This was similar to the problem i had been having in that i could still alt-tab over to the toon after the message was displayed that it had left the world.  I then take a step forward with that toon and i get the loading screen.  The toon would then re-connect.   Toons continuously dropped out of the game.

 

Memory leak issues were minimal when all toons were on.  I had 8 toons logged in on Xan and 1 logged in on Indy.  Most of my time was spent running around Indy and that toon had no lag issues.

 

Edit:  Neglected to mention that i got several disconnect dialogue box messages today.  Each time i got one it mentioned a particular toon being idle too long in the first sentence.  Did not get this everytime, but got it several times.  I was not getting this prior making Keenan's suggested changes today.  I would also like to add that my cpu load reduced quite a bit after making the changes.

Edited February 28, 2016 by newman330
completeness

[JakeRivers 2,921]

Tried this out last night after a good friend of mine held my hand and walked me through the configuration process.

 

So riding from one side of chaos to the other required no client restart at all, very nice and the fans and hard drive on my pc never once went into crazy mode, I would say this is a great help.

 

Thanks Keenan

[Keenan 5,539]

Thank you everyone for the feedback!

 

So what I'm seeing in the messages and posts here is pretty much what I thought I would be seeing. The initial performance increase is both from the thread count drop and the new GC. Both use less CPU. The reason performance still drops is that Java is still not "forgetting" things as it should. I've been working hard on trying to sort that issue out, and I know the relative area where I need to look.

 

I've also had some report crashes. If anyone crashes with this, please copy and paste the console log from the crash window that pops up and stick it in a pastebin for me, or email it to keenan@wurmonline.com - if you don't see a crash window, check your Desktop or Wurm folder for an hs_err_pidXXXX.log file, where the X's are numbers and send that. Check the date, make sure it was created when you crashed.

 

Just a little note on how garbage collection:

Since memory can't be explicitly freed, in other words we can't decide that XXX_model is done being used and should be removed - and then remove it ourselves - memory usage will not drop immediately upon leaving an area with a lot of models. Sometimes it does, sometimes it takes quite a while.

 

My hope was that this little tweak would offer some a way to play the game more than they can now. If anyone was able to log in and do more than they have in recent weeks, then I'm quite happy.

[MootRed 193]

how would we use this for Wurm Unlimited?

[Keenan 5,539]

25 minutes ago, MootRed said:

how would we use this for Wurm Unlimited?

 

Navigate to: (Your result may vary, essentially where Steam installed WU).

C:\Program Files (x86)\Steam\steamapps\common\Wurm Unlimited\WurmLauncher

 

Next, open LaunchConfig.ini and add the JvmParam1= line. You can also tweak your heap size here if you wish.

[Runtime]
OverrideDefaultJavaPath=false
JavaPath=
[Memory]
InitialHeap=512m
MaxHeapSize=2048m
[VMParams]
JvmParam0=-XX:+AggressiveOpts
JvmParam1=-XX:+UseConcMarkSweepGC

 

[Mini 0]

Just had a 5 v 14 derp about and not a bit of lag once!

Keenan is the man!

[MarkSilard 194]

Don't know if my experience  has anything with this (don't know much about programming). Used your settings and it works better now. Still when was traveling fast, i got significant FPS drop, from 60 to  10, even drops to 0 fps for a few seconds. But thing is, at the moment I looked down under my feet, fps restored to 60 and was running smooth even  with   10+ players in local and  close to deeds loaded with tons of stocked items and different kind of buildings and ton of  colored lamps. So is that fps drop related  with  drawing models in your field of view?

[Keenan 5,539]

44 minutes ago, MarkSilard said:

Don't know if my experience  has anything with this (don't know much about programming). Used your settings and it works better now. Still when was traveling fast, i got significant FPS drop, from 60 to  10, even drops to 0 fps for a few seconds. But thing is, at the moment I looked down under my feet, fps restored to 60 and was running smooth even  with   10+ players in local and  close to deeds loaded with tons of stocked items and different kind of buildings and ton of  colored lamps. So is that fps drop related  with  drawing models in your field of view?

 

So as you're moving through the world, the client is basically doing this:

Loading what's ahead of you, even if it's not yet visible. This includes textures and animations.

Unloading what is behind you.

Then rendering your field of view, which can include loading new LOD models and animations.

 

The faster you move, the less time you give the client to perform all of these actions and the more models (trees, structures, players, creatures, etc) around you, the more work it has to do at each step.

 

 

[MootRed 193]

6 minutes ago, Keenan said:

 

So as you're moving through the world, the client is basically doing this:

Loading what's ahead of you, even if it's not yet visible. This includes textures and animations.

Unloading what is behind you.

Then rendering your field of view, which can include loading new LOD models and animations.

 

The faster you move, the less time you give the client to perform all of these actions and the more models (trees, structures, players, creatures, etc) around you, the more work it has to do at each step.

 

 

 

with that said, if you have an alt that you want to run in the background or if you are traveling a long distance quickly, put the alt in the cave to render less and look at your feet when traveling!

[Keenan 5,539]

Just now, MootRed said:

 

with that said, if you have an alt that you want to run in the background or if you are traveling a long distance quickly, put the alt in the cave to render less and look at your feet when traveling!

 

This, for sure. As an aside, I would like to see if I can improve No World Rendering some for this, but I consider that a feature improvement - so priority is much lower. Fixing the bug here is top.

[Tinkerer 107]

I've been using this since you first posted, often for hours on end wihout any memory issues or disconnects. The only time I hit lag was when I was logged in with a toon on Xanadu and lots of folk came into the local area for the treasure hunt. However, even that lag was nothing compared to what it is usually like with more than a few people in the local area. It was laggy, but I was still in control of wurm rather than the previous 'not responding' scenario.

 

My laptop isn't great, AMD Turion 64 x2 2.0Ghz, ATI mobility radeon x1300, 4gb ram.

Running wurm, the memory footprint is pretty stable - even after hours of playing at just over 1gb. It only changes depending on whether I am above or below ground. Input responses and movement are much much smoother - almost feels like mouse sensitivity increased tenfold. Everything scrolls smoothly when turning etc, rather than in incremental steps.

 

The only noticeable thing is when moving continually forward. Every couple of tiles there is a slight 'judder' as it obviously loads/unloads the new distance parts of the area. This is very minor compared to the HUGE increase in every other area. I'm running it with 2gb reserved for Wurm and on 2 model loading threads.

 

The last couple of days have been great

[Jaz 2,666]

I had a single crash while riding - never happened before as I remember and still was fine after relog until the server been shut down (riding all the time out hunting).

Your recommended command line settings but heap size 4096 (8GB RAM here).

 

http://pastebin.com/606PPtq2

[Jaz 2,666]

Been on extensive hunting trip yesterday on Cele using the .99w unstable client, been online for several hours, riding up and down quite a lot of kilometers. No noticable travel lag at all. Client memory consumption was a stable 2GB (with manual heapsize set to 4GB)

Had no chance to test with many in local, at most we were 3-4 in local tab.

Very promising, thanks for the hard bugbashing!

Edited March 1, 2016 by Jaz