Memory usage runs rampant about pulsepro HOT 11 CLOSED

Thanks for putting it through its paces. I'll check where the memory usage is coming from.

It shouldn't be the data blobs – these are stored on disk. Maybe just NSManagedObjectContext in-memory objects. What are you logging primarily: plain logs, network requests, or both?

Yes, there is currently no cap on the log files saved on a Mac during remote logging, and there probably should be and it should be configurable.

from pulsepro.

In this particular case, I believe it was logging both network requests (every few seconds) and a few general messages.

from pulsepro.

The good news is that I can reproduce it, and it runs great on iOS. The bad news is that I have no idea how to explain this much memory usage on macOS.

I created a sample project where I'm writing 100 small messages per second. Memory usage on iOS went from 50 MB to 51 MB after writing 4000 messages. On macOS, it went from 50 MB to 800 MB. In both cases, I'm on the list of messages that are constantly updating using the same mechanism (NSFetchedResultsController). I can't even being to comprehend how 4000 messages that take about 1 KB each can account for 750 MB. Investigating...

from pulsepro.

I'm glad you can reproduce it! I didn't mention that I was on an M1, if that matters. If you want another set of eyes on it, I'd be more than happy to take a look.

from pulsepro.

I'm still on Intel. Thanks, but I'm planning to keep it closed-source for now. A bit embarrassed by the code tbh.

I'm close to finding the culprit. It's not any of the data storage code. I ran the app in headless mode while still keeping all the ViewModels running and refreshing. After writing 3000 small messages, the memory usage increased from 39 MB to 40.5 MB. It looks like the UI (SwiftUI?) is the culprit (some layers are not released?).

from pulsepro.

OK; sounds good and the offer will stand if you want me to take a look. Feel free to contact me even if you don't intend on open sourcing it.

from pulsepro.

It was the toolbar. Looks like a common issue http://openradar.appspot.com/FB9453009. I'm trying to see how to mitigate it.

from pulsepro.

Yes, the root cause was the toolbar leaks. I stopped most of the bleeding. I'll release a new build later today when I finish testing. I also optimized CPU and disk usage.

Previously, the app was adding about 30 MB per minute just sitting idle and receiving messages ... not great to say the least.

Now, it's down to about 3 MB per minute when writing 1000 messages per minute. Pretty good, but I think I can improve it even further.

There are still a couple of toolbar leaks that you can trigger by actively using the app. These leaks are likely fixed in Monterey. I'm going to test the latest beta sometime later to confirm that.

from pulsepro.

Thanks! I am noticing that the app hangs after a little bit and then recovers. Hopefully it is the memory issue.

from pulsepro.

Performance is much better! I haven't noticed hangs and am running it all day long.

from pulsepro.

Great, I'm glad the main issues are resolved! I have a couple of ideas how to optimize it further.

from pulsepro.