10th
EventBox’s Performance Issues
I feel that some of those issues need explaining. There are three problems at hand which manifest themselves in different but similar ways. So, here they are:
- Slow startup / hangs during refresh
- Memory ballooning over time
- High memory usage
I’ll try to shed some light on those. Firstly though, a word on memory leaks.
Memory Leaks
Users normally associate high memory usage with memory leaks because that’s a term circulating around. In simple words, a memory leak is some part of memory which you have allocated but you’ve “lost” along the way.
In terms of memory waste, there are two main categories:
- Memory you’re wasting because you’ve lost the reference to it
- Memory you’re wasting because you’re forgetting to give it back
The major difference between the two is that in the first case you don’t have a reference to the memory while in the latter you do.
Now, let’s go back to EventBox.
Slow Startup / Hangs During Refresh
This performance problem is caused by having a lot of events. It’s a purely computational problem and doesn’t have anything to do with memory. The reason for it is that we’re performing a lot unnecessary sorts. In order to keep those hangs to a minimum, you could try locally deleting events you’re not interested in.
Memory Balloon
This is an interesting one. Symptoms include very high usage memory usage over time (it starts normal but then goes through the roof). It’s not a memory leak and was introduced recently (in 565). We’ve identified the issue and it’s related to the networking component which was rewritten. It’s the same piece of code which caused the proxy problems for a lot of people. We plan to issue a bug fix release (probably 570) which will revert back to the old networking stack.
High Memory Usage
Now this is the most interesting problem. Again, it’s not a memory leak but a property of our interface architecture. In computing, there is always a trade-off between space / time. You have two choices (and obviously a wide spectrum inbetween):
- Compute the answers to the “question” beforehand and save them in memory. When you need those results, they are readily available and it takes no time at all to retrieve them (negligible in practice).
- Compute the answers when they’re needed. So, every time you need the answer to the same question, you will recompute it.
That’s the space / time tradeoff. So how’s that relevant to EventBox’s memory problem? We made the wrong choice (retrospectively) picking to use more memory instead of re-computation.
The good news is that it’s fixable. The bad news is that it’s non-trivial to do so and it will take some time - rewriting it requires a lot of changes in quite a few modules. We’ve been prototyping the new architecture and I’m pleased at the preliminary results. I think we will be able to get EventBox to use about 40-45MB (maximum) in 90% of usage scenarios. You might be wondering when this will be ready? We don’t know. Once it’s done and usable, we will let you know, that’s for sure.
