Hi, As a user of the EFLs, I've found tmpstr to be quite painful. I was jointly supervising other people and I'm quite certain that dropping a few tmpstr instances and going for something plain and simple solved at least a couple bugs. That was a couple years ago so I don't remember the specific but I do remember that it wasn't one of the APIs I've loved the most.
When it comes to locks for thread-safety, it's good to remember that the libc's malloc is quite likely going to take a lock too so it's not an argument in favor of one or the other (jemalloc tries to avoid the need for them but I think glibc doesn't). In any case, if you look at Tom's example of getenv(), I'd say the call to getenv() is probably to be what's slower by quite a large margin. You gave the example of genlists but when would performance for this matter? Scrolling. So you'd have to malloc() space for a string and at the same time you're also free()'ing space for a string for a widget that became invisible. If your libc's malloc() is not completely crap then it's likely going to be fast. And if it is crap, fix it (or you're going to be like the openssl devs that went for a broken custom mempool and you know how this ended). >From my perspective: save bugs, save kittens, avoid unneeded optimizations. And since I'm siding with Tom on this one, I'll also side with him on saying that the benchmark that's needed is the one that would be in favor of tmpstr and would therefore be work from not I. :) -- Adrien Nader http://win-builds.org - package manager for windows: cute EFL GUI ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
