Performance drops drastically after 300,000-600,000 frames

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Record a long (10+ min.) demo, and use it for rendering, noting starting 
framerate.
2. Wait while a few hundred thousand frames render
3. Note the poor, jumpy framerate, start-stop-start-stop behavior of the game, 
and java.exe maxing out one CPU core.

What is the expected output? What do you see instead?
The program should maintain the same framerate throughout long renders, but 
does not.

What version of the product are you using? On what operating system?
2012-04-07. Win 7 x64. 32-bit JVM.

Please provide any additional information below.
Poor performance. Usually flips back and forth between my usual 30 to 4 
repeatedly: http://i.imgur.com/zJwc7.png

Performance data. Note the spiky read IO and consistent 11-12.5% CPU usage (1/8 
cores): http://i.imgur.com/k0AKW.png

Render settings:
Output FPS: 30
Blur multiplier: 32
Shutter angle: 180
Gaussian blending: No

If I had to guess, I'd say this is caused by a memory leak invoking GC every 
few seconds (note that java.exe is using almost all it's available memory), in 
which case the program should crash soon when the GC can't free enough memory. 
If I wasn't several hours into a render, I'd turn on verbose GC and check my 
assumptions; I might do so when my current render finishes/crashes. I'll leave 
it running overnight, and report its status when I get back.

Original issue reported on code.google.com by lx45...@gmail.com on 28 Dec 2012 at 5:00

[GoogleCodeExporter]

This is due to a memory leak in JDokan. You can watch the program in JVisualVM 
and you'll see a ton of net.decasdev.dokan.ByhandleFileInformation objects 
building up over time. I've added some workarounds in SrcDemo2 to make it 
create as few of these objects as possible, which helped a little, but it's 
just a workaround and doesn't solve the underlying problem which I believe to 
be in the JDokan code (the native side of it, which is why it's out of reach to 
fix).

This being said, SrcDemo2 ships with a version of JDokan I downloaded quite 
some time ago. Perhaps things have been fixed? It looks like it has been 
updated in August 2011. Try using that new version. You can download it here:
https://code.google.com/p/opendedup/downloads/detail?name=JDokan.zip
You should only need the .jar and the .dll files from this archive. Let me know 
how it goes.

Original comment by windypo...@gmail.com on 28 Dec 2012 at 5:40

• Added labels: OpSys-Windows, Usability

[GoogleCodeExporter]

I couldn't find JDokan.jar anywhere, so I've only replaced the .dll for these 
tests.

If there is any improvement, it's so small I can't even tell the difference 
between it and sampling noise. (I only ran two tests; I've only got one window, 
and it's already enough of a window nightmare) I ran the tests using a 360 
blend rate and 1 degree shutter angle with low quality jpg compression and no 
audio to maximize engine fps. Heap usage growth between GCs and whatever those 
huge jumps are was 93.3 KB/s with the current dll, and 92.4 KB/s with the new 
one. Not a lot of data, but if there is any real improvement in there, it's not 
worth the effort.

I have a pretty beefy computer at my disposal, what would help mitigate the 
problem further? A larger heap allocation and careful GC tuning, splitting the 
JDokan-related code into a separate thread, something else? If I can just push 
it to 20-30 minutes at 30x32 fps, I'll finally be able to show my friends just 
how I wipe the floor with them in Hidden.

Original comment by lx45...@gmail.com on 28 Dec 2012 at 8:12

[GoogleCodeExporter]

Sadly there is little that can be done, because JDokan.dll is a 32-bit DLL and 
thus requires a 32-bit JVM to run, which in turn limits the JVM to at most 2 GB 
of RAM. Currently the launcher sets the max heap size to 1024 MB as written in 
launcher/SrcDemo2Launcher.py. You can try pushing it further but I'm not going 
to make such a change to the main codebase, because 1024 MB is already too much 
for this sort of application, especially since this is memory it shouldn't have 
to be using up to begin with.
You can override SrcDemo2Launcher.py's setting by using the undocumented 
--jvm-args argument it takes, like this:
SrcDemo2.exe --jvm-args="-Xmx1536M"
or something like that. You can check if it works by looking at the final 
command flags in the task manager.

If you want a more permanent solution, and if Hidden has an OSX version, you 
can try using SrcDemo2's Mac version which doesn't suffer from this because it 
uses fuse rather than Dokan+JDokan. Or you can do it in Linux too, SrcDemo2 
works fine there but getting Hidden to work there might be a challenge. You can 
probably get it running in Wine but it won't look as good as it would in 
Windows, which kind of ruins the point.

Otherwise, what I recommend you to do is to deal with it and render the demo in 
multiple parts. That's what I did for my hour-long Dear Esther walkthrough, had 
to restart the process every so often. You can render a demo partially by 
playing the demo normally, then run the host_framerate and startmovie commands 
right when it's about to get to the part where the previous render stopped. 
Then later on in your video editor you'll have to synchronize them and 
crossfade their audio, but it shouldn't be too hard.

Good luck and thanks for testing that other JDokan.dll

Original comment by windypo...@gmail.com on 29 Dec 2012 at 1:43