Clojurians Log v2
clojure-dev 2023-06-28
I decided to pick up the glove regarding the ask issue I opened map equivalence using kvreduce, and I have a couple of questions, one practical, one less so • all the functional tests pass. How would you test performance improvements? • I find that I really dislike my implementation, it has about 8x the amount of code I would have wanted. Once for equals/equiv, once for java.util.Map/IPersistentMap. Additionally, since APersistentMap doesn't implement kvreduce, the core implementation is duplicated between PersistentArrayMap and PersistentHashMap. GAH, how do I clean this up?
Link?
haven't pushed to git yet
this is the gist:
maybe I could unify the implementations if I implement getOrDefault on APersistentMap
yeah that counts down on the duplication
I mean, link to the issue
oh
To run the benchmarks without interference with external tools I went with
clojure -A:CLOJURE_VERSION -M src/io/github/bsless/map_equiv.clj(spoiler, my patch looks way faster, better than 2-3x for maps of 1-128 elements)
Need to construct test cases and acceptable benchmarking methodology
you need to step back and be categoric about what you're finding. 1. why is it faster, just logically? 2. what abstractions that already exist in Clojure convey those capabilities or constraints? I think if you can answer those questions, you will be on the path to an actual problem. Once you have a well-stated problem, you can then easily come up with some new ideas for multiple places you could make changes. Then, make a table that compares those and evaluates the tradeoffs. I suspect there will be one or maybe two leading options. I would not bother to write any code until then, as it's probably the wrong code. If you want to walk down this process, I am happy to do this work async with you, but answer the questions above as clearly as possible first.
Tyvm Alex, I'll take you up on this offer