Two ideas that *might* work:
1) is hashing the key - that is, if you can represent the Vector{Int} as an
immutable type (say, by somehow quickly changing it into an Int64 or
Int128, perhaps using hash()) then you store the computed result as the
key. The thing to keep in mind here is that if you mutate the vector, you
will mutate the hash as well. That is likely what you want, but it's good
to be explicit. You will also not be able to "go back" unless you create a
separate dict with the hash values as a key and the Vector{Int} as the
value.
2) is creating two data structures: one is a Vector{Vector{Int}}, the other
a Dict{Int, Vector{Float64}}. The index of the first data structure is the
key of the second, and it should be* faster to check the former against a
given vector then going through a dict. Unlike #1, the index will NOT
change if you mutate the inner vector.
On Monday, April 13, 2015 at 1:56:55 PM UTC-7, Will Kearney wrote:
>
> I'm hoping I can get some advice on optimizing some code.
>
> I have a data structure which is very conveniently represented as a
> Dict{Vector{Int},Vector{Float64}}. That is, I need to look up
> floating-point vectors stored at certain multidimensional (usually 2-10)
> positions represented as a Vector{Int}. Before I construct this Dict, I
> don't have a priori knowledge of what position vectors will be represented.
>
> I'm aware of the problems of using mutable objects as Dict keys, but let's
> assume that's not really an issue.
>
> Profiling reveals that the real time sink is testing arrays for equality
> when indexing into this data structure, and indexing happens very
> frequently. What would be a good way to speed this process up?
>
> Is there a way to represent the keys which will be cheaper to compare? I
> could convert the keys to tuples, but it's helpful to have them as mutable
> arrays to do some calculations with them at certain points.
>
> Is there a different data structure which might work better? Should I roll
> my own hash table implementation which is particularly optimized for vector
> keys?
>
