Hi Sebastian, Given that you added eina_strbuf, how about doing tests in eina/src/tests? The test format is quite simple, and using the coverage support should say how much of it is covered. Most of the tests should be quite straight forward, just remember possible corner cases with head/tail removing addition.
It would be also good to have some kind of benchmarking against glib. Last but not least, a long but simple to fix review. If you or someone else can do it it, please help, otherwise I can fix them tomorrow: - some getters could me marked as "const Eina_Strbuf" as this pointer is not modified; - add safety-checks (see other code in eina); - unset magic check before you free buf (eina_strbuf_free()), so you get the errors dealing with garbage deleted buffers; - return Eina_Bool in methods that may not work (due memory failures or so); - set eina error to indicate out of memory (see eina_list()); - check if _eina_strbuf_grow() worked. - no need to eina_strclpy() if you know the string size (eina_strbuf_append() and most of other places!) - rewrite _resize function using pure-math, no need to loop, you can just divide/multiply, etc. - add a _dup() variant that returns the copy of the string (you know the size beforehand, so you can use malloc + memcpy instead of strdup) - rename _string_remove() to _string_steal()? remove seems you're removing part of the string After benchmark with glib (others?) we can try some optimizations. Suggestions: - user configurable initial/base step - account how many append/prepend/insert operations you required before realloc, if < 20 (or some other limit), double the step, soon it will stop requesting frequent realloc. You can choose to multiply the initial/base step instead of doubling the previous value (that would make it exponential), and in all cases I'd still check for EINA_STRBUF_MAX_STEP. More aggressive optimizations would include a chunked/paged buffers. We'd have a linked list of inital/base step buffers, never reallocating, just appending/prepending blobs of that size. That could also benefit from mempool. Going even further we could allow these chunks to be partially filled, even the first/middle, avoiding memcpy() all around, of course the management of this is even more cumbersome. To the user it would be the same, with eina_strbuf_string_get() compressing them all into a single string before returning. The problem with this approach is that operations such as remove/replace become a pain and definitely is not worth until we have tests to cover 100% of our current code base so we can test it. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
