Code center > Darwinbots3

Release date

<< < (9/11) > >>

Moonfisher:
That's a nice trick, I'll have to remember that when working in native code.
But I would definately write a comment with the "normal" way of doing it and probably mention the conditions for the values used.
Probably make a function that used that method when the parameters where met and otherwise the normal way.

I know you don't need to optimize everything to an extreme degree, but if you have a feeling the feature you're working on will be used frequently you may aswell optimize it right away. And often optimized code isn't much harder to read, you don't have to go completely nuts writing everything in assembly language, just managing memmory and not passing strings and such will make a significant diffrence and would barely make the code any harder to read... IMO pointers aren't that bad, just takes a litle getting used to with all the referencing stuff.
Ofcourse if a function is rarely used it's not going to make a significant difference, although if you have a lot of heavy functions they can add up.
But so far it seems to me that a lot of the features made in a game engine will get called very often when they're in use. Or if it's triggered by an event of some sort there's a risk it can happen too many times at once. I can immagine people getting carried away, but I guess any optimization will help if you're already straining the processor with lighting and physics and such... so it may actualy make a noticable difference in the long run, I'm not sure how far they take it, but I know some of the native code is way beyond my understanding and I don't think they did it for fun  (But I would imagine that when you want to sell a game engine it's good to optimize almost everything since you don't know how often people are going to use certain features.)

Numsgil:
Yes, there are certain features that you know up front need to be optimized, because you have prior domain knowledge (you worked on an engine before and this part was slow).  Global knowledge helps too (this function is inside a tight loop that gets called 1000 times every game cycle).  But even with these cases, if you write the code to be fast first, you're making a mistake.  The problem is that, trivial optimizations aside, you don't know for sure what's going to be fast and what's going to be slow.  Modern computers have all sorts of caching issues, math coprocessors, etc., that change from year to year and change what sort of optimizations you need to make for your hardware.  Optimizations always assume something about the hardware your using (it has SSE, or it uses bits, that sort of thing).

As an anecdote, there's a popular sqrt approximation that Quake used involving bit manipulations and some adds and multiplies.  Sqrt calls were a bottleneck for the Darwinbots Visual Basic code.  I naively replaced some sqrts with these approximations, and just assumed it would be faster.  I believe it was Sprotiel who actually profiled and showed me that my Quake approximation was actually slower than a native call to sqrt.  I don't know exactly why.  Probably modern processors have a hardware level sqrt function that just beats any software approximation I could write.

Moral of the story here is even if you think you know exactly how and where to optimize, use a profiler anyway.  At no point should you make a change for the sake of optimization without profiling before and after.

Trafalgar:
By the way, what do you use for profiling in C#? (Last time I looked, I didn't find any free or open-source ones)

Profiling without an actual profiler is a bit of a pain. Running a loop which calls a function several thousand times, and timing how long it takes, doesn't necessarily give you results which reflect the actual real-world performance of the function, as far as I could tell.

Numsgil:
Performance hasn't been an issue with any C# apps I've done yet, but I think the professional edition of Visual Studio (which I have) has some in-built profiling.  A quick google search also led me to this page.

bacillus:
Have you heard of a tool called Clover? It searches through the code and checks which code is not covered by test cases. This could be useful as there are an enormous amount of things to be tested, by the looks of it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page