Module 12: Performance and Memory Tuning
Performance advice is easiest to remember when it is attached to a real mistake. That is why this case study is valuable. Instead of repeating general rules, it shows how ordinary-looking decisions in a real application created noticeable problems and how those problems were fixed.
The first example is a perfect reminder not to trust first impressions. The contacts demo seemed slow for an obvious reason, but profiling and inspection uncovered a different issue entirely: the same resource file was being loaded repeatedly in places where the code looked superficially innocent. That kind of bug is common because the expensive part is often hidden behind constructors, helpers, or convenience APIs.
The second example is equally important because it shows the limits of the “just move it to a background thread” reflex. Loading contact images off the EDT sounded like the right fix, and in one sense it was. But the background work still competed with the user experience during scrolling. The real improvement came from coordinating the work with user activity so the app deferred expensive updates until interaction settled down.
That is a strong pattern to remember. Performance is often not about doing less work overall. It is about doing work at a better time. If the UI is busy, defer the optional work. If the user is idle, use that moment to fill in detail. This is one of the cleanest ways to improve perceived and actual responsiveness at the same time.
So the real lesson from the case study is methodological. Do not assume. Measure. Look for hidden repeated work. And when a background task still harms the experience, ask whether the issue is not the work itself but its timing relative to user interaction.