Program Performance Monitoring

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
Benny the Bear
Posts: 146
Joined: Sat Oct 27, 2007 2:44 am UTC
Location: Melbourne, Australia
Contact:

Program Performance Monitoring

Postby Benny the Bear » Tue Jun 03, 2008 4:39 am UTC

Hi,

I'm making a game where the user can spawn objects that bounce around with physics. I would like the player to be able to spawn as many as possible without slowdown.

Anyway, I was wondering if there was a way to produce and integer from an object that determines how much memory it is consuming so I can tell a performance improvement from this rather than what I remember to be its original 'smoothness.' That, or something that could achieve the same effect.

Also, can anyone recommend me a lightweight drawing library? I'm using the GDI thing (well, System.Drawing and System.Drawing2D) and I hear it's rather slow.

The less fancy the better, so far I've only used the System and my own libraries.

Notch
Posts: 318
Joined: Tue Dec 12, 2006 5:52 pm UTC
Location: Stockholm, Sweden
Contact:

Re: Program Performance Monitoring

Postby Notch » Tue Jun 03, 2008 1:07 pm UTC

For collision handling, memory use has almost nothing to do with performance.
It's much better to focus on ways to avoid checking large bunches of objects in a single go.

For example only checking objects that move towards each other will, on average, eliminate 50% of the tests. Doing fancy space partitioning eliminates even more. Even if you make each individual test slower by adding this type of logic, your overall gain is going to be "off the hook" (I believe that's the technical term).

User avatar
Xanthir
My HERO!!!
Posts: 5426
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Program Performance Monitoring

Postby Xanthir » Tue Jun 03, 2008 5:54 pm UTC

Notch wrote:For collision handling, memory use has almost nothing to do with performance.
It's much better to focus on ways to avoid checking large bunches of objects in a single go.

For example only checking objects that move towards each other will, on average, eliminate 50% of the tests. Doing fancy space partitioning eliminates even more. Even if you make each individual test slower by adding this type of logic, your overall gain is going to be "off the hook" (I believe that's the technical term).

RFC57220 redefined this. The appropriate term is now "off the hizzy".
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

Ipswitch
Posts: 47
Joined: Tue Jun 03, 2008 1:54 pm UTC
Location: Bowling Green, OH
Contact:

Re: Program Performance Monitoring

Postby Ipswitch » Tue Jun 03, 2008 7:00 pm UTC

Well, the easiest way to tell the "performance" of a piece of code is to use a profiling debugger to gather a runtime profile of the software in action. This incurs an overhead on the running executable, but if the performance while profiling is acceptable then actual performance should be acceptable as well.

However, before you go to that length, you can tell what the performance and scaling implications of your software is going to be from the code itself. How big are your objects in memory? Are they consistent sizes (don't internally allocate memory) or do they change? Do they get larger or smaller? How do I access these objects? Can I optimize my algorithms to access fewer objects? Can this algorithm be reduced to fewer steps?

In regards to the purpose of your original question, to maximize the number of objects in your game you're going to want to use not only the lightest data structures but also the ones that let you use the most efficient algorithms to work on them. I'd look towards optimizing both your collision detection and physics handling to reduce the number of game objects they each need to process. Also improvements in your drawing logic could reduce the time the program spends in the display routines.
http://vogonpoetryreview.com

"We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defense, promote the general Welfare..." -- U.S. Constitution

User avatar
Benny the Bear
Posts: 146
Joined: Sat Oct 27, 2007 2:44 am UTC
Location: Melbourne, Australia
Contact:

Re: Program Performance Monitoring

Postby Benny the Bear » Wed Jun 04, 2008 7:53 am UTC

Nice idea on the collision, that's a bit in the future though. I guess I'd sort through the list of objects with ones had have a certain velocity in relation to the object checking for collision.

As for my drawing routines, I'm using GDI. If I want speed, I'll probably have to swap that for something else. Right now the objects change position and redraw themselves (in their paint handler) every 24ms.

How would I get a profiling debugger? Is it something Visual Studio would have?

So there's no way to measure how much an individual object takes? i.e. 128k?

Ipswitch
Posts: 47
Joined: Tue Jun 03, 2008 1:54 pm UTC
Location: Bowling Green, OH
Contact:

Re: Program Performance Monitoring

Postby Ipswitch » Wed Jun 04, 2008 3:26 pm UTC

A profiling debugger is part of Visual Studio (at least the last version I used, VS6 Pro). Check out the debugging menu.

The best way to figure out the size of your objects is sizeof(). It should give you a rough estimate of the object size. There's some things it won't include in it's byte count, so it may not be the exact byte count, but it'll be close.

The fastest drawing is going to be the kind that's hardware accelerated. Used to only be OpenGL and DirectX were directly accelerated under Windows, but Vista and Aero changed all that. I, however, am unsure of what's-what with that topic anymore.
http://vogonpoetryreview.com

"We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defense, promote the general Welfare..." -- U.S. Constitution

arcoain
Posts: 56
Joined: Thu Dec 20, 2007 12:34 am UTC

Re: Program Performance Monitoring

Postby arcoain » Sat Jun 07, 2008 7:53 pm UTC

For drawing, I'd reccomend TV3D (truevision3d.com) its a little fancy, but fast and easy to use. Otherwise, OpenGL is very fast, but a pain to use (find a nice tutorial and you should be fine though). DirectX is also a perfectly acceptable way to go. But none of that matters if drawing isn't your bottleneck. Run some tests without drawing and see if your simlulation speeds up a lot, a little, or none at all. If theres no dramatic performance increase, no need to use a fancy lib; gdi is doing the job just fine. That said, graphics are probably more of a bottle neck the computation. Consider running computation more often then you update the graphics.

arcoain


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests