Design notesThis page contains notes abou implementation details in current or previous version of libyuri, design of 3.0 should be on separate page. Container for planesFrom version 2.0, the planes were stored as a std::vector of shared_ptr's to the class BasicPlane<T>, that was wrapping boost::shared_array<T>. As I'm trying to remove dependecy on boost from the core library (so v3.0 could have core dependent only on c++11), I had to abandon shared_array and look for alternatives. The most obvious STL replacement was std::vector<T>. The biggest issue with using std::vector was the fact that it initialized the values inside. This is perfectly correct and desirable for classes and general store, but for our purpose it was a bit inconvenient. Having the vector initialized is nice, but it comes at quite high price during creation/resize. There's no replacement in current (C++03) STL, so I decided to create own class (yuri::uvector<T>) that would have the same interface as std::vector, but would internally work with uninitialized storage. In order to support the reasoning about allocation price, I conducted testing, for type T=uint8_t (which is used as yuri::ubyte_t in libyuri) with following results:
The testing array had 5MB and the test were conducted 100000x. Conclusion: uvector beats std::vector when it comes to simple creation (as expected) and it's performance for different variants of copying is similar. There's more than 10% speedup in std::vector when copying data compared to uvector. Using uvector instead of shared_array seems to give faster creation (no reference counting here) and the copying performance is basically the same. std::vector would be even faster, but the creation times are just to high. Using vector with it's capacity only allocated (using reserve) is UB, so we definitely want to avoid that. |