On Mon, Feb 9, 2015 at 7:45 PM, Adrien Nader <adr...@notk.org> wrote:
> 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. > Daniel said the same. I personally never felt the need to try it. I just had to fix it because it was wrong and confusing. > > 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). > I actually just copied the example from the docs. Also, just to clarify something, tmpstr does a malloc *AND* has its own lock. So two locks. :) > > >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. :) > I appreciate your undying support. ------------------------------------------------------------------------------ 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
