INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: Matt on December 19, 2012, 03:11:33 pm
-
I stumbled onto a pretty neat speed-up. It's a little geeky, but I'll explain it anyway.
Any time there's a graphic in Media Center, it's a thing called a JRImage. To paint the screen, hundreds of these JRImage objects work together.
At its heart, a JRImage is a 32-bit bitmap image using the pixel format ARGB. Any drawing between these objects uses our own code (normally SSE).
But since we used to be hooked a little more closely to the system, these images were created using a Windows API. The Windows API uses two GDI objects (HDC / HBITMAP) for each image. Windows limits each program to 10,000 GDI handles, so we're limited to around 5,000 images.
But now that the font engine in v18 uses our own drawing, there's no longer a need to use system resources for most JRImage objects.
This leads to several performance improvements. I'll describe them below:
JRMark
The image creation portion of JRMark gets around 3x faster, making the image score of JRMark over 10% faster.
Lower system resource usage
You can view GDI object usage in Task Manager. Starting the program to an image view used around 550 before, and now uses around 150. Scrolling a huge list of files used around 6000 handles (we cap the cache at 3,000 items because of the limit discussed above), but now stays around 150.
Memory state
An unexpected benefit of the change is that now it's tightly defined what is inside an image right after it's created. Previously, the program would allocate an image then flush it. Now it's guaranteed to be flushed when it's created, so a bunch of areas of the program can skip the extra flush step.
The performance aspect of this one surprised me. If you allocate empty memory (using calloc or HeapAlloc(HEAP_ZERO_MEMORY)), it's _way_ faster than allocating memory and then emptying it as a second step. The OS must keep a pool of empty pages or something, because the difference was like 1000x or more in the JRMark test.
So, like I said it's a little geeky.
The take away is that the program just got faster and less resource intensive, and hopefully geeks and non-geeks alike can appreciate that.
-
Things like this (you taking the time to tell us about internal geekiness) are one of my favorite aspects of this forum. I don't quite understand the specifics, but follow the concept, and really appreciate the benefits it provides.
I'm glad you take time to share these kinds of things with us.
thanks.
-
Showing the promised speedup on Windows 7 here:
18.0.94:
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 5.038 seconds
Single-threaded floating point math... 3.005 seconds
Multi-threaded integer math... 2.568 seconds
Multi-threaded mixed math... 1.538 seconds
Score: 1564
Running 'Image' benchmark...
Image creation / destruction... 1.659 seconds
Flood filling... 1.005 seconds
Direct copying... 1.913 seconds
Small renders... 2.070 seconds
Bilinear rendering... 1.448 seconds
Bicubic rendering... 1.331 seconds
Score: 2334
Running 'Database' benchmark...
Create database... 0.815 seconds
Populate database... 2.282 seconds
Save database... 0.220 seconds
Reload database... 0.062 seconds
Search database... 2.156 seconds
Sort database... 1.736 seconds
Group database... 1.263 seconds
Score: 2519
JRMark (version 18.0.94): 2139
18.0.98:
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 5.033 seconds
Single-threaded floating point math... 2.997 seconds
Multi-threaded integer math... 2.594 seconds
Multi-threaded mixed math... 1.521 seconds
Score: 1564
Running 'Image' benchmark...
Image creation / destruction... 0.495 seconds
Flood filling... 1.155 seconds
Direct copying... 1.922 seconds
Small renders... 2.073 seconds
Bilinear rendering... 1.452 seconds
Bicubic rendering... 1.335 seconds
Score: 2609
Running 'Database' benchmark...
Create database... 0.840 seconds
Populate database... 2.329 seconds
Save database... 0.218 seconds
Reload database... 0.062 seconds
Search database... 2.151 seconds
Sort database... 1.682 seconds
Group database... 1.096 seconds
Score: 2566
JRMark (version 18.0.98): 2247
-Leezer-
-
I'm seeing an overall jump of about 5% to the JRMark (lost the before stats when it rebooted on the upgrade)
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 3.225 seconds
Single-threaded floating point math... 2.135 seconds
Multi-threaded integer math... 1.048 seconds
Multi-threaded mixed math... 0.657 seconds
Score: 2689
Running 'Image' benchmark...
Image creation / destruction... 0.184 seconds
Flood filling... 0.365 seconds
Direct copying... 0.525 seconds
Small renders... 0.904 seconds
Bilinear rendering... 0.656 seconds
Bicubic rendering... 0.599 seconds
Score: 6807
Running 'Database' benchmark...
Create database... 0.339 seconds
Populate database... 1.203 seconds
Save database... 0.284 seconds
Reload database... 0.071 seconds
Search database... 0.798 seconds
Sort database... 0.824 seconds
Group database... 0.550 seconds
Score: 5283
JRMark (version 18.0.98): 4927
-
Sounds very good Matt. Glad to see that some of this cross platform stuff is paying of.
-
I like geeky things.
Thanks for sharing.
-
And for implementing it of course ;D
-
Hello Matt,
Also on heaps, are you using the default heap or do you have many? Heap access are serialized (unless you specify HEAP_NO_SERIALIZE, but then you have to manage concurrent access yourself) so having separate heaps for concurrent tasks sometimes help if a lot of allocation/deal location are done. You can avoid contention with that.
Great job on the improvements!