Site Sponsors:
Linkedin: How can my code be faster than STL algorithms?  
Linkedin asks: "Something is wrong and I don't know what. How can my code be faster than STL algorithms?"

My Response:

"Many often find that custom code creates faster solutions. In general, generic solutions produce generic results?

Here your test cases work well for what you have envisioned. Yet if you want to see a REAL performance boost, then pre-allocate your <T> memory for the anticipated usage, only to grow by similarly-sized blocks; Base allocations upon a rounded-up, architecture specific (64 bit?) sub-allocated power of 2. Thereafter, if the preferred usage is required to be full CRUD, consider using a linked list and a pack() scenario for sub reallocation and no one will be able to touch your speed.

For even faster results, from there we might use inline assembly language so as to base those blocks upon Intel Page Selectors... Why? Because calling 'new' all the time is always a performance bottleneck. Using Intel page selectors directly for memory sub-allocation will be allot f-a-s-t-e-r. --But is it worth the effort?

Get the idea? Generic solutions can almost always be improved upon by by custom means / coding to support a particular problem domain. Many times – when screaming performance is required - it can even be better to simply junk generics all together... It all depends upon what one is trying to accomplish?


Add Comment
Comments are not available for this entry.