Thanks for the examples. Point 3 is interesting but most of the gain there could probably be had by telling the user to use (bigmap `union` smallmap). My guess is that the user has a good idea which argument is larger/smaller.
On Wed, Feb 23, 2011 at 12:45 AM, Max Bolingbroke <[email protected]> wrote: > Personally I don't find any of these *particularly* compelling. But a > ~6% slowdown for this functionality is not too bad - have you had a > chance to look at the core to see if the cause of the slowdown > manifests itself at that level? Perhaps it is possible to tweak the > code to make this cheaper. I did look at the core for test :: HashMap Int Int -> HashMap Int Int test hm = insert 42 12 hm And I didn't see anything that looked particularly bad. The core uses unboxed values everywhere possible and the recursive function (i.e. inserts) returns an unboxed pair (# Int#, Tree k v #). The code for O(1) size i here: https://github.com/tibbe/unordered-containers/commit/77bc43acad2eb6b29472cd6ea21c3efb677cae0d > Also, what was the size of the collections you used in your benchmark? > I would expect the relative cost of maintaining the size to get lower > as you increased the size of the collection. I tried with 2^12. Johan _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
