Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

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.

[JustinChase]

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.

[leezer3]

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-

[jmone]

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

[MrHaugen]

Sounds very good Matt. Glad to see that some of this cross platform stuff is paying of.

[InflatableMouse]

I like geeky things.

Thanks for sharing.

[InflatableMouse]

And for implementing it of course 

[SoundChaser]

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!