Frogboy Frogboy

The importance of optimization

▼

The importance of optimization

from JoeUser Forums

When I was a kid, the Amiga could multiask on 512K of memory and run some pretty darn good games.

My Commodore 64 was a blast to play and required less memory than a typical modern icon image.

Today, we live in an age where the resolutions are so large, the textures do detailed that we need lots of memory.  I think most people recognize this.

But one thing we really tend to focus a lot of attention on is performance.  Readability in code is important but so is performance.  This week, we’re doing a lot of work on making sure our algorithms are efficient to ensure that the game runs well on lower end systems.

It’s not just a point of pride. It’s not just dealing with a pet peeve. But there’s a good business justification – the better the performance, the more PCs it’ll run on.

78,486 views 32 replies
Reply #26 from Elemental Forums Top

Quoting Fenrus, reply 20
I suspect that I'm not the only person who has pre-ordered Elemental who still plays Master of Magic and LOVES IT to this very day!  It's all about the gameplay, as far as I'm concerned.  Sure, graphics and sound effects and a nifty soundtrack are nice...  But give me rock solid gameplay and replayability and I'll play your game for decades.

+1

Reply #27 from Elemental Forums Top

Quoting Moussu, reply 25
Yes you're right. Before optimizing you have to measure and figure out what to optimize.

My point  about giving a size is when knowing how many items will be inserted (forgot to specify it, my bad), like after getting back some data from a database. So at that time you may initialize the dictionary with the size of the query result, before inserting items.

It's simple, efficient and does not take 1 month to measure it or to implement. So why wait until a "slow" system when it can be done right at the beginning, when coding the 1st time?

And there is dozen other "case" like that..

 

A lot of times something like that is the developer in question simply not being aware that you can do it, or of the benefits. There are some very gifted minds doing programming, and a lot of others for whom its just a job like any other. For the latter group, they know that they can stick stuff in the dictionary, but don't know that you can speed it up so easily and either don't have the motivation to look, or simply don't have the ability to remember things like that. A framework like .net is so big that a lot of the people using it have huge gaps in their knowledge of it, they know the minimum needed to get the job done, and thats it.

Not trying to justify it, but I understand why it happens so often. Option Strict being off in VB.net is similar silliness, that's just a bad default that many people don't know to change despite the enormous benefits.

CursorFX - Customize your Windows cursor
Reply #28 from Elemental Forums Top

Quoting Moussu, reply 25
Yes you're right. Before optimizing you have to measure and figure out what to optimize.

My point  about giving a size is when knowing how many items will be inserted (forgot to specify it, my bad), like after getting back some data from a database. So at that time you may initialize the dictionary with the size of the query result, before inserting items.

It's simple, efficient and does not take 1 month to measure it or to implement. So why wait until a "slow" system when it can be done right at the beginning, when coding the 1st time?

And there is dozen other "case" like that..

It's true that if you know the size in advance, giving the size to the dictionary doesn't hurt at all and helps performance. But really, is this such a big performance gain to say that if someone is not putting it he has forgotten about performance?

From my point of view, most of those things are micro-optimizations, which most of the time don't make any significant impact on the overall picture. Usually the most important optimizations come from design rather than tiny details of the .NET framework internals (which are important to know, I won't argue that, I wish all C# developers out there were forced to read CLR via C# and C# in Depth).

Reply #29 from Elemental Forums Top

Hi guys and gals.

I've been working on making the performance of the game's graphic engine better.  Someone mentioned batching, and I'll assure you that from the start I've had the engine batching lots of stuff.  One of the things that has really improved performance this week is looking at when and how often those batches are updated.  There have been a lot of other tweaks too that will make the game run even peppier.  Performance has been a concern of mine from the very start of the project and I have a low end machine at my desk that I use to test the game periodically to make sure it still runs in an acceptable manner.  In fact, at this very moment, I'm about to test something on the old machine.  Wish me luck :)

 

+1 Loading…
Reply #30 from Elemental Forums Top

Quoting CodeCritter, reply 29
In fact, at this very moment, I'm about to test something on the old machine.  Wish me luck

Here's me hoping that everything turns out nice and that it will run on my notebook as well. ;)

Reply #31 from Elemental Forums Top

Good luck!

Reply #32 from Elemental Forums Top

Quoting VicenteC, reply 28

But really, is this such a big performance gain to say that if someone is not putting it he has forgotten about performance?

It depends on the application. If you run on this "case" some few time, no. If you may need to add thousands of elements or add into a new one very often, yes, you may see the difference. 

Quoting VicenteC, reply 28

Usually the most important optimizations come from design rather than tiny details of the .NET framework internals (which are important to know, I won't argue that, I wish all C# developers out there were forced to read CLR via C# and C# in Depth).

I agree. Until now, I never see a case where optimization can "fix" a design flaw. And, as Tridus said, maybe this is more a problem of knowledge. But somehow, I think it's part of developer responsibility to think more than just "do code that works", and maybe it's due the environment I'm working on.

Anyway, I'm very happy that Stardock people take care about performance early in the dev process, and not as other does, when the product is out and only if there is plenty people complaining about performance issues.