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
I was using Yourkit to measure memory consumption (through strong references) after a few phases while doing quick.lib and quick.comp. Here are my results:
which uses a copy of Java's WeakHashMap. The reason I had to copy the whole implementation of WeakHashMap is that we need an access to getEntry method which is package protected so there's no other option to just copy that class (and some of its dependencies) to our own package. That was meant just to try the idea.
It looks like we'll need to implement our own WeakHashSet one way or another. If we go down that route we might be able to squeeze a little bit more of memory because we don't need value field in Entry object for sets.
Implementing my own collection is a bigger task that I can spend time on right now so I just leave this ticket open were we have potential benefits documented.
The text was updated successfully, but these errors were encountered:
I experimented with making
Types.uniques
a weak hashset in this branch:https://github.com/gkossakowski/scala/tree/weak-unique-types
I was using Yourkit to measure memory consumption (through strong references) after a few phases while doing
quick.lib
andquick.comp
. Here are my results:Optimized here means we used locker build out of the following commit:
gkossakowski/scala@85c8e26
which uses a copy of Java's WeakHashMap. The reason I had to copy the whole implementation of WeakHashMap is that we need an access to
getEntry
method which is package protected so there's no other option to just copy that class (and some of its dependencies) to our own package. That was meant just to try the idea.It looks like we'll need to implement our own WeakHashSet one way or another. If we go down that route we might be able to squeeze a little bit more of memory because we don't need
value
field inEntry
object for sets.Implementing my own collection is a bigger task that I can spend time on right now so I just leave this ticket open were we have potential benefits documented.
The text was updated successfully, but these errors were encountered: