duplicate map.get() causes duplicate observers?

[nyura123]

here's a small example:

const m = map({a:0})
const disposer = autorun(() => {
    console.log("RUNNING a="+m.get('a'))
    m.get('b')
    m.get('a')
})
//Display observers of m.a
console.log(JSON.stringify(m._data.a.observers.map(o=>o.id+' '+o.name)))

output:

RUNNING a=0
["5 Autorun","5 Autorun"]

Should we avoid calling .get() more than once within the same derivation? That might be difficult if it calls other functions which might get the same data.
I had a React component that observed & sorted 1000 items, and when it was unmounting, the root map had around 200K observers (so unmounting took a while).

[mweststrate]

in general there is not much need to optimize those calls away. in the map example both entries are needed because a and b can be changed independently.

the sorting might be a lot more efficient if you slice the list first. probably that should be a standard optimization.

mobx does by default a lot of feed deduplication in the observers list. see observable.ts reportObserved and quickDiff in utility. it is basically a trade off between cpu and memory. from measurements it turned out that in general more aggressive deduplication made mobx slower.

[nyura123]

Thanks! I'll try slicing the array - though in my case it's just an array of keys and I look up the fields to sort by in an observable map. I'll build an array with all the fields pre-looked up before calling sort on it.

Btw I tried to build mobx with a change to do a lookup of observable.id before adding it to observing and while it greatly speeds up my specific case, it slowed down the mobx tests by almost a factor of 2 (!) So yes, probably not a good tradeoff.

[mweststrate]

Haha yeah I tried that as well a while back. I'm thinking of doing something more smart in the future, change the observers storage strategy from array to object if the list becomes too long or something similar :) It is a fully internal concept, so a lot of tweaks can be done in this area