Hello,

On Mon, Feb 9, 2015 at 3:19 PM, Tom Hacohen <tom.haco...@samsung.com> wrote:
> Let's talk about tmpstr again. After raising my concerns last week
> regarding tmpstr_strlen, today I actually dove in to the code and fix
> the major (solvable) issues with tmpstr.
>
> The biggest problem with tmpstr, is that it's broken by design, and I
> don't see how this could easily be solved.
>
> So what is tmpstr?
> According to the docs, tmpstr is there to let you be able to easily
> return strings from functions without caring about freeing the data.
> Example:
>
> Eina_Tmpstr *my_homedir(void) {
>    return eina_tmpstr_add(getenv("HOME"));
> }
>
>
> void my_movefile(Eina_Tmpstr *src, Eina_Tmpstr *dst) {
>    rename(src, dst);
>    eina_tmpstr_del(src);
>    eina_tmpstr_del(dst);
> }
>
> char buf[500];
> my_movefile("/tmp/file", "/tmp/newname");
> my_movefile(my_homedir(), "/var/tmp");
>
>
> This is essentially a wrapper around an allocated string that lets you
> differentiate between a static string and a string you need to free.
>
> At the moment it's implemented as a linked list of strings that need to
> be searched every time you call add/del/len, and because it's threadsafe
> it also acquires locks. This sounds painfully slow, and to be honest
> normal strlen() would probably be faster than the tmpstr_len() in most
> cases, or in other words, pointless waste of cache space.
>
> To be honest, I just don't see how this really helps compared to a
> simple malloc/free (which it kinda does anyway). I'd maybe also replace
> the linked list with a hashtable. I just don't get it. Would like to
> think what the rest of you have in mind.

I think you just don't understand the usecase. The lock could be
optimized away in most case, but the main point is that there is at
any point in time very few tmpstr alive. The size and cost of using an
Eina_Hash is only meaning full when you are well above 10 items in
your list. So this is just not the point of this api. As for the lock,
I don't think it is also a meaningful issue, you are already using
malloc and free with a string... lock is going to be really not your
problem. Anyway, as always with optimization, before saying anything,
show me a benchmark ! A real life one !
-- 
Cedric BAIL

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to