TechPrufer
Get started
Slack
Slack logoSlack · Feature trail

Desktop Client Memory Optimization

3 posts · Jan 2017 – Mar 2017

What this trail covers

This thread tracks the evolution of Slack's desktop client, focusing on reducing its memory footprint and improving performance. Initial posts detailed the problem of high memory consumption due to multiple webviews per team. This post details the refactoring of message fetching to a lazy-loading model, avoiding the need to fetch all message history upfront. It also covers the lessons learned from aggressive caching in LocalStorage, including its performance issues, size limitations, and complex.

All Slack trails
  1. Reducing Slack’s memory footprintIntroduced a 'tiny client' for backgrounded teams to reduce memory footprint. This involved teaching servers to calculate notification counts, determine desktop notification eligibility, and track unread status. Developed a new API endpoint for 'has_unreads' and 'mention_count' stored in memcache, and a new 'desktop_notification' message type distributed over websockets. The tiny client is a single JavaScript file of ~1200 lines. The desktop application manages swapping between the full and tiny clients based on team usage.
  2. Making Slack Faster By Being Lazy: Part 2This post details the refactoring of the Slack desktop client to implement lazy loading of message history, avoiding the need to fetch all messages upfront. It also discusses the lessons learned from aggressive caching in LocalStorage, highlighting its synchronous blocking I/O, storage size limitations, potential for database corruption, and added complexity from compression and web workers. The post concludes that LocalStorage was ultimately detrimental to performance and led to increased complexity, prompting the decision to ditch message history from LocalStorage and store only ephemeral, user-created data.
  3. Making Slack Faster By Being LazyThis post details refactoring the Slack desktop client to improve performance by adopting a lazy loading approach for message fetching, only loading messages for the currently active channel instead of all channels. It also discusses using the `users.counts` API to efficiently display unread and mention states in the channel list, and prioritizes pre-fetching messages for DMs, group DMs, and channels with mentions. The post also covers using 'frecency' (frequency + recency) and keyboard shortcut cues for smarter preloading, and contrasts performance timelines before and after these optimizations, highlighting reduced JavaScript blocking, DOM updates, and memory churn.