On Tue, 17 Apr 2012 10:36:38 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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. > THAT'S WIZARD'S CHESS! ------------------------------------------------------------------------------ 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
