I spent quite a lot of time trying different versions back then, and nothing really stood out. I went through the profiler, and it wasn’t one thing – it looked like multiple things just took longer. I’m planning on getting back to it in the following months, but that’s about it for now. I also thought it may be related to the Node.js version (or even V8), but my experiments were inconclusive (i.e., it wasn’t always worse with the newer version).
Thanks for that. I guess we’ll have to just try it out ourselves and see if it affects us or not 
Are there plans for anyone from Meteor to look into this? I’m wondering if you guys have a test app with some performance tests that compare pub-sub / method speeds across different versions ?
I looked into it (I’m not a 100% Meteor guy, though 
), and I did not reproduce this problem in a few other applications (both small and decently sized). It wasn’t a very in-depth investigation, but it seems to be related to some publication patterns or packages.
Curious, what odd behavior were you seeing with reactive-aggregate?
Hey, so we were actually trying to figure this out this morning and we found it’s not actually the fault of that package. It’s more to do with a mix of how the aggregation unwind and tabular interplay. So if you do a lookup and then unwind but don’t specify preserveNullAndEmptyArrays and have some docs where there’s nothing to join - you’ll have less docs than expected by tabular so its behaviour is to wait to have all the docs before updating (which will never happen) rather than listening to when the publication is ready. So just adding preserveNullAndEmptyArrays: true inside our unwinds has fixed it.
3 Likes
I thought I’d mention here that we upgraded from 2.7.3 → 2.10.0 a week ago and haven’t seen any performance hit at all with extensive publishComposite use. After reading this I had expected a hit. Our DB is running the latest 5.x if that’s of interest.
1 Like