Thanks to your answer

Le lun. 30 mars 2020 à 14:56, Vladimir Sitnikov <[email protected]>
a écrit :

> >https://github.com/JCTools/JCTools) instead of Dexx HashMap?
>
> They serve for completely different use cases.
>
> JCTool's map is for concurrent operation (like Java's ConecurrentHashMap).
> That is when a map needs to be accessed from multiple threads, and each
> thread should see updates that come from the other threads.
>
> However, JMeter needs quite the opposite.
> JMeter needs a map that pretends to be **non-shared**.
> I other words, the map should support updates, however, each thread should
> see **only** its own updates.
>
> What JMeter currently does it **clones** maps. So a single
> "FlowControlAction" is stored millions times in the Java heap
> since JMeter clones the test plan for each and every thread.
>
> What we need is a way to share "the common values", however, all the
> updates must be put to separate storage.
> This is exactly what Dexx collections do.
>
> Of course, Dexx is not the only implementation, however it was the best for
> performance-memory footprint ratio when I explored the libraries some time
> ago for https://github.com/vlsi/compactmap
>
> Vladimir
>

Reply via email to