On Tue, 17 Apr 2012 00:18:02 +0200 Cedric BAIL <cedric.b...@free.fr> said:
> On Mon, Apr 16, 2012 at 7:47 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: > > On Sun, Apr 15, 2012 at 2:06 AM, Daniel Fitzpatrick > > <doubleagen...@gmail.com> wrote: > >> In messing around with creating Clojure bindings for the EFL, I decided to > >> do some performance benchmarks on the low hanging fruit. Since we're going > >> through a binding layer (the JNA), I wanted something from the > >> clojure-world which would help balance the scales a bit more. Since > >> Clojure's split operation handles regex, making the code more complex, I > >> felt that would help. I suspected these to be about even, but they were > >> not what I'd suspected. > >> > >> ; eina_init called somewhere up here.... > >> user=> (ave 1000 (vec (eina/eina_str_split > >> "Calvin;Leoben;D'anna;Simon;Dora2;105Rl;Six;Daniel;Sharon" ";" 0))) > >> 0.08763943600000001 > >> user=> (ave 1000 (split > >> "Calvin;Leoben;D'anna;Simon;Dora2;105Rl;Six;Daniel;Sharon" #";")) > >> 0.008177458999999986 > >> > >> > >> This tells it to perform the split operation 1000 times and then give the > >> average number of milliseconds elapsed for each execution. Any ideas why > >> eina is so much slower? > > > > eina_str_split() is quite naive implementation and not optimized. It > > does 3 pass over the string: 1) strlen(); 2) count tokens to allocate > > memory; 3) populate tokens on return value. > > > > The first strlen is stupid and is being used to check for empty > > string... no idea why it got in. The second and third steps could be > > joined using realloc and growing at an incremental step. This could > > help the performance a bit. > > > > In the case of a max_tokens is provided, it could pre-allocate the tokens > > array. > > > > Last but not least there are optimizations to be applied to the > > character match, doing word search (8 chars on 64bits) instead of > > byte... > > > > OTOH, it's quite space efficient for the return value, a single > > allocation is done to contain it all. > > > > But is it really useful? Does it matter? > > Well, small change like removing strlen could be done. But yes, does > it really matter, I never saw that function showing up in any > benchmark. In fact, that's certainly the main reason it is slow. It > never did hurt anyone. So if it hurt you, then patch are welcome :-) actually the eina impl even if ALL it does it malloc the array to hold 1 string AND then strdup the string is still 2x as slow as the clojure version. i've tested. simply allocating (and freeing afterwards0 alone is 2x the overhead. if you didn't free - u'd save some time, but it's even slower as u baloon in memory and probably hurt caches. if you have some kind of simple mempool recycler + gc it may be doable, but as such as long as we allocate the returned array we will never be as fast. i actually have my doubts and think clojure is optimizing things. it can ASSUME something like "EINA_PURE" as u always hand in the same input string to a method known to always produce the same output from the exact same input. with a trivial test case like this a good compiler could optimize this out to just recycle the previous result. i don't know for sure, but the fact that u can onl get to half the same speed with 1 malloc, 1 strdup, and 2 frees in c, leads me to think its doing something hyper-funky that defeats the benchmark. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
