Dmitry Kakurin wrote: > Thanks Alex, this is a VERY elegant solution. Hehe. I think I got a bit carried away generalising mine, but I found it interesting. :-) I think your way or Meikal's juxt (which is really neat, I didn't know about juxt) is much better for this specific problem. I guess mine is more suited for when the 'groups' are derived from the data (like the 'SQLalike' examples Timothy came up with) rather than predefined by the code.
> But there is still ex-C++ programmer sitting inside my head, screaming > "Aaaaah, so many temporaries and lookups, this is so inefficient" :-). > I'll try to make "him" shut up by comparing perf with my multi-filter > approach. > On my PC your multi-filter is 3-4 times faster than my last reduce-by version, which I guess is not too bad considering my version has all those lookups and temporary objects (I tested by filtering a large range of integers into groups divisible by 2, 3 and 6). The JVM seems to be actually pretty fast at creating objects and Clojure does lots of little tricks to speed up lookups, like caching hash codes and using vectors instead of hash tables for small maps. To quiet my inner premature optimisation fanatic I usually rationalise with "the disk is going to be the bottleneck anyway" and "lets try the first way that occurs to me and only if it turns out to be too slow in practice only then tweak it". --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
