Timeline for Fast variable-length stack allocator for vector<> in C++
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 7, 2018 at 13:31 | history | edited | Deduplicator | CC BY-SA 3.0 |
typo
|
| Mar 7, 2018 at 13:04 | comment | added | Toby Speight | I have to disagree with the comment that "there is no point in writing slower code" - it does depend on whether the cost outweighs the benefit. If you double the speed of 1% of your program, when you could have been taking 10% off the execution time of 10% of your program, you've only made half the performance gain you could have done. And as well as opportunity cost, we have to consider the maintenance cost - time spent fixing bugs or understanding non-obvious code is clearly not time spent contributing to improvements. | |
| Feb 16, 2017 at 20:32 | comment | added | MathuSum Mut | I sense your unnecessary mistrust towards my ability to code. What I'd like to remind you is that an optimisation is an optimisation. There is no point in writing slower code (even by a slight margin) for no reason. With all due respect, I get that you're trying to warn me of any dangers that may ensue, but rest assured that I more aware of all implementation details than you may realise. There is no reason to coddle myself with slower code for the sake of a needless false sense of security. :) | |
| Feb 16, 2017 at 20:09 | comment | added | Loki Astari | 7 nano seconds to 1 nano second is an insignificant speed up. So saying it is 7 times faster is a false measurement. To make a comparison you need the actual times it takes. Then we also need the context it is being used in. If you have written bad code then sure you can optimize the bad code it is still bad and could be faster if just written properly (like hiking the vector out of nested loops and simply resetting). Without further context we really can't say anything constructive apart from the code above is brittle and unlikely to be useful in most contexts. | |
| Feb 16, 2017 at 19:55 | comment | added | MathuSum Mut | Of course, that goes without saying. I wrote a simple benchmark, and the stack-allocated vector of 128 integers was approximately 7 times faster to allocate than 128 integers on the heap. The benefits are significant given the right circumstances. | |
| Feb 16, 2017 at 17:25 | comment | added | Loki Astari | @MathuSumMut: Given that you can only resize the once. I don't think you will gain any speed. This kind of optimization for speed is only useful if you are doing it billions of times. Since you only do it once I don't believe this code gains you anything; apart from brittle code. | |
| Feb 16, 2017 at 5:24 | comment | added | MathuSum Mut | Indeed, flexibility has definitely been traded-off for speed of execution. I only intend to use it for personal projects where I want to make use of vector features such as insert while still pretty much retaining the allocation speed of stack arrays. :) | |
| Feb 16, 2017 at 0:38 | comment | added | Loki Astari | @MathuSumMut: Not sure that test proves anything. You are testing the state after the object has been resized. The problem will occur during a re-size. But you are probably correct in the it will not happen if your first action is to reserve the maximum space available and never force re-allocation (Which sort of wastes all the work in your allocator you may as well simplify it to the point where it does no work). Sure it will work for your use case but that does not change its brittleness thus making it not very suitable for general coding or re-use and a definite headache for maintainers. | |
| Feb 15, 2017 at 21:17 | comment | added | MathuSum Mut |
I tested whether the assertions made above actually hold true using the following test code: pastebin.com/Y9C1tXUh, but the test results were all correct as expected. This is probably due to the Name.reserve(Size) statement in the init_stack_vector() macro.
|
|
| Feb 15, 2017 at 20:34 | vote | accept | MathuSum Mut | ||
| Feb 15, 2017 at 20:02 | history | edited | Loki Astari | CC BY-SA 3.0 |
deleted 356 characters in body
|
| Feb 15, 2017 at 19:53 | history | answered | Loki Astari | CC BY-SA 3.0 |