reporter: respect existing elements in dictionary#538
Conversation
| // hash value of the key. To get the correct order for profile.StringTable, | ||
| // put the values in stringMap, in the correct array order. | ||
| stringTable := make([]string, len(stringMap)) | ||
| tmpStringTable := make([]string, len(stringMap)+int(strDicOffset)) |
There was a problem hiding this comment.
Yes - this can become a massive waste of memory, as strDicOffset of elements are just empty elements ...
dic.StringTable() is missing a functionality like AppendEmpty(), as EnsureCapacity() is not sufficient to grow the underlying data structure.
The helper elements, like stringMap and FuncMap, in setProfile() assumed, that they are the only and always the first that write to protocol global dictionaries. This is not correct and so while the content of these helper elements were appended to the according dictionaries, the references were not correct (as they always started at 0). Fixes #534 Thanks @fandreuz for reporting this issue. Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
| case support.TraceOriginSampling: | ||
| st.SetTypeStrindex(getStringMapIndex(stringMap, "samples")) | ||
| st.SetUnitStrindex(getStringMapIndex(stringMap, "count")) | ||
| st.SetTypeStrindex(getStringMapIndex(stringMap, strDicOffset, "samples")) |
There was a problem hiding this comment.
In Async-Profiler we created a small abstraction to ease this process, and we fill the string table in order after all profiles have been processed. Maybe you could consider something similar? Passing around offsets seems a bit error prone.
There was a problem hiding this comment.
I consider this more of a hot patch and let the options open for #515.
There was a problem hiding this comment.
Yeah right. Every table in ProfilesDictionary could benefit from such an approach. Not just functions and locations.
|
I fixed this in #550 by introducing a new type, |
|
Closing in favor of #550. |
3 participants
The helper elements, like stringMap and FuncMap, in setProfile() assumed, that they are the only ones and always the first that write to the protocol global dictionaries. This is not correct and so while the content of these helper elements were appended to the according dictionaries, the references were not correct (as they always started at 0).
Fixes #534
Thanks @fandreuz for reporting this issue.