On 09/02/15 15:13, Cedric BAIL wrote:
> 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 !
>
I actually followed this email with a comment (to Daniel) on IRC, that a
10 items long array would probably be way more efficient than both the
hash and the list.
I think I understand the usecase, but just don't think it's a valid one,
especially not at this cost. That's why I sent the email...
As for the benchmark: whoever added it claiming it was better should
provide benchmarks, not me.
--
Tom.
------------------------------------------------------------------------------
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
