Ich Heisse Super Fantastiche
So i just finished profiling my new font system and it's over twice as fast as the old one - hurrah!
When i first profiled it it was a bit slower than the old one and i was slightly confused - how could code that demonstrably did less actually be slower?
Well i found the answer hidden away in a clear() function for our vector class. A vector in this case is a list of items (an array) which dynamically grows as more items are added. A specification called the Standard Template Library (STL) exists which implements a std::vector class but this is not particularly console friendly so we avoid using it and have our own (CVector, funnily enough). STL specifies that when one clear()s an stl vector, the data contained should be scrapped but the allocated memory retained. Handily, however, the Microsoft implementation of std::vector (as i have been testing on a PC thus far) doesn't conform to this, and does de-allocate the memory. And oddly, our CVector class does too. Bizarre. I would have thought that for a piece of code which to all intents and purposes attempts to duplicate STL functionality (at least, from the outside) this would be a reasonably salient point to adhere to.
Now, i don't dare change it as the code base is quite large and it may result in a lot of extra memory being used up! However, at some juncture i shall probably test it.
Any road up, as they say, the problem was that i was calling clear() on the CVector. It should be noted that the old version of the font stuff was using a STL vector, and here we can use erase(begin(), end()) to get the required functionality. However, like i said, CVector is a better choice here.
Rather than rewrite the clear() functionality of CVector i decided to add another data structure, CStaticVector. It gives us vector like functionality (seemingly dynamic allocation) on a fixed size array. The other advantage of this is that it allows us to do bounds checking too, to ensure we don't attempt to read or write to memory outside of the array. C and C++, unlike Java, don't do this for us, which is one of the reasons that they are faster.
When i first profiled it it was a bit slower than the old one and i was slightly confused - how could code that demonstrably did less actually be slower?
Well i found the answer hidden away in a clear() function for our vector class. A vector in this case is a list of items (an array) which dynamically grows as more items are added. A specification called the Standard Template Library (STL) exists which implements a std::vector class but this is not particularly console friendly so we avoid using it and have our own (CVector, funnily enough). STL specifies that when one clear()s an stl vector, the data contained should be scrapped but the allocated memory retained. Handily, however, the Microsoft implementation of std::vector (as i have been testing on a PC thus far) doesn't conform to this, and does de-allocate the memory. And oddly, our CVector class does too. Bizarre. I would have thought that for a piece of code which to all intents and purposes attempts to duplicate STL functionality (at least, from the outside) this would be a reasonably salient point to adhere to.
Now, i don't dare change it as the code base is quite large and it may result in a lot of extra memory being used up! However, at some juncture i shall probably test it.
Any road up, as they say, the problem was that i was calling clear() on the CVector. It should be noted that the old version of the font stuff was using a STL vector, and here we can use erase(begin(), end()) to get the required functionality. However, like i said, CVector is a better choice here.
Rather than rewrite the clear() functionality of CVector i decided to add another data structure, CStaticVector. It gives us vector like functionality (seemingly dynamic allocation) on a fixed size array. The other advantage of this is that it allows us to do bounds checking too, to ensure we don't attempt to read or write to memory outside of the array. C and C++, unlike Java, don't do this for us, which is one of the reasons that they are faster.
posted by Jonny Hopper at 2:14 PM
0 Comments:
Post a Comment
<< Home