Profile: Faster data dict lookup

[IanButterworth]

The ip -> stackframe lookup that happens when viewing profiling data dominates TTFPP and TTSPP

Master

julia> @time ProfileView.view()
 20.764135 seconds (2.68 M allocations: 304.669 MiB, 0.48% gc time)

which is basically all spent in getdict! within retrieve

julia> @time Profile.retrieve();
 20.858307 seconds (1.87 M allocations: 172.837 MiB, 0.36% gc time)

julia> @time Profile.retrieve();
 20.861972 seconds (1.87 M allocations: 172.837 MiB, 0.83% gc time)

This PR

julia> @time Profile.retrieve();
  1.891498 seconds (3.50 M allocations: 314.141 MiB)

julia> @time Profile.retrieve();
  2.110156 seconds (3.50 M allocations: 314.143 MiB, 8.65% gc time)

so

julia> @time ProfileView.view()
  2.392356 seconds (4.41 M allocations: 450.986 MiB, 14.13% gc time, 1.23% compilation time)

And when julia only has one thread it takes the same amount of time as master.

[vchuravy]

I always forget if Dict is threadsafe. I don't think it is?

[IanButterworth]

I thought it was if it's preallocated like it is here?

[IanButterworth]

At least experimentally they seem to be?

julia> dict = Dict{Int,Vector{Int}}();

julia> foreach(i -> dict[i] = Int[], 1:10_000)

julia> @sync for i in keys(dict)
           Threads.@spawn begin
               dict[i] = collect(1:i)
           end
       end

julia> for i in keys(dict)
           sum(dict[i]) == sum(1:i) || error()
       end

julia> 

[vchuravy]

Ah yes as long as we are not reallocating...

[vtjnash]

No, this is a very bad idea

[timholy]

Since unique uses hashing which is much of what Dicts do, why is this a speed improvement?

[IanButterworth]

That just facilitates identifying the unique ips before going off to parallelize. It's the parallel part that helps most