You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are uses cases where compactness is quite important and we're working with unboxable types like Ints (or newtyped wrapped ints) where it'd be nice to have hash table that uses an unboxed vector for the keys and values. (These cases also tend to want inplace updates of the values, issue #6)
For such an application I hacked up the implementation to add a variant of Basic that uses unboxed vectors rather than boxed ones. I had to make some adjustments to the type class to allow this, but it doesn't affect the existing implementations too much. It just changes how we declare the instances, and it affects generic code in the IO wrapper.
So this is an RFC. In particular, @gregorycollins would you be interested in unboxed variants of the existing implementations? If so I can try and tidy up what I hacked up quickly and we can look at different ways to adjust the class to allow for both boxed and unboxed variants.
The text was updated successfully, but these errors were encountered:
@dcoutts I also have a use case for unboxable types, and I'd like to look at your "hacked up implementation." Would you please push your branch to Github, or publish it somewhere?
Unboxed versions would be fine! They would surely perform better than the current ones, which are hampered by single-threadedness in the garbage collector.
There are uses cases where compactness is quite important and we're working with unboxable types like Ints (or newtyped wrapped ints) where it'd be nice to have hash table that uses an unboxed vector for the keys and values. (These cases also tend to want inplace updates of the values, issue #6)
For such an application I hacked up the implementation to add a variant of Basic that uses unboxed vectors rather than boxed ones. I had to make some adjustments to the type class to allow this, but it doesn't affect the existing implementations too much. It just changes how we declare the instances, and it affects generic code in the IO wrapper.
So this is an RFC. In particular, @gregorycollins would you be interested in unboxed variants of the existing implementations? If so I can try and tidy up what I hacked up quickly and we can look at different ways to adjust the class to allow for both boxed and unboxed variants.
The text was updated successfully, but these errors were encountered: