
Reducing Slack’s memory footprint - cpeterso
https://slack.engineering/reducing-slacks-memory-footprint-4480fec7e8eb
======
bborud
Slack has to be one of the worst pieces of software I have seen based on what
it does and how it behaves. It gobbles CPU and memory to do something that
should require neither. It is offensively wasteful.

~~~
mordant
And yet Slack runs just fine on my 2016 12" MacBook, iPhone 7 Plus, and iPad
Mini 4.

~~~
bborud
I suppose you may not know any better. And I am not saying that to be mean,
I'm merely pointing out that your frame of reference _may_ not be the best to
judge how well the desktop Slack client was done with regard to resource use.
You may not understand just how few resources the desktop client could
reasonably be expected to consume.

And you would not be alone. Over the past 7-8 years I'd had to teach people
how to benchmark things. I see people measure things and then use their first
result as the performance reference. Sure, they can see relative changes, but
if you are orders of magnitude off a reasonable result, a relative reduction
of a few tens of percent is still orders of magnitude off.

As a developer you should have an idea what a _reasonable_ number ought to be.
For CPU, for memory, for latency, for anything you care to measure.

"It runs just fine" isn't data. It isn't a useful metric for performance.

~~~
joekim
> "It runs just fine" isn't data. It isn't a useful metric for performance.

I don't see any claims from "mordant" that their anecdote is a useful
performance metric. If anything it'd be a data point that could be used as a
user experience metric. ie. X% of users in the target demographic agree with
this statement, "works fine for me."

The point was a counter to your claim of Slack being, "offensively wasteful".
Further, isn't "offensively wasteful" equally useful as a performance metric?
If you're experienced in performance perhaps you could share some of your
"reason numbers" and contrast that to measurements your made against the Slack
client.

~~~
bborud
By "offensively wasteful" I mean off by orders of magnitude. At which point
the problem isn't one of mere programming but of actually having some idea of
what you are doing.

Recovery from this state of affairs doesn't happen by telling people how to
fix concrete, individual things, but teaching them to think about what they
are doing and to analyze things. In order to know when you are off by orders
of magnitude you need to have some idea of what is reasonable before you
measure. If the reality you achieve is way off what is reasonable, you either
need to change your perception of what "reasonable" is or you have to face the
possibility that you may not have done a good job.

A chat client that deals with perhaps 3-4 teams and perhaps 200-300 people
should not require 1Gb of memory and it should consume a negligible amount of
CPU. Any way you slice it that's a LOT of resources per user, per team or per
communication volume. So Slack miserably fails even cursory glance at
workload/resource usage.

You can start off with the lower layers: speaking a chat protocol. How much
resources should that eat up? For a chat application: too little to measure on
a modern machine. (I spent most of the early 2000s working on web-scale web
crawlers on much, much weaker server machines than even cheap desktop machine
is today). The IO should have trivial cost, the protocol parsing should
likewise have trivial cost or you have messed up badly.

Then move on to the internal state. Draw it on paper. What are the main
structures you will be needing. How much data do you need to keep in memory,
how much space does it need to take, how do access it and manipulate state?
What is a reasonable CPU expenditure?

Next is the UI. How do you make it responsive. How do you make it not gobble
up tons of memory. Are there tradeoffs you can make? How do other applications
do things? Where are the resources wasted?

One doesn't produce a resource hog like Slack by doing one or two things in a
wasteful and sloppy manner. One does it by having the wrong attitude and
systematically doing a bad job.

~~~
joekim
Thanks for your response. I generally agree with the technical approach, but
not with your assessment of Slack's products.

> By "offensively wasteful" I mean off by orders of magnitude. At which point
> the problem isn't one of mere programming but of actually having some idea
> of what you are doing.

That would imply that Slack, doesn't know what they're doing. Slack is an
extremely successful company. I myself use it for several teams
simultaneously. From a user and business perspective it generates a lot of
value and that ultimately trumps criticisms of their implementation.

> One doesn't produce a resource hog like Slack by doing one or two things in
> a wasteful and sloppy manner. One does it by having the wrong attitude and
> systematically doing a bad job.

Perhaps what you're taking into consideration isn't broad enough. Going back
to the original comment, if they did such a bad job, then why am I able to get
a lot of value from it? Their implementation seems "good enough".

What's the negative consequences of their "orders of magnitude" performance
problems? Does it destroy it's business value? What would you do if you were
the CEO? Cease all active development and re-build everything in scratch in
c++?

~~~
bborud
I'm not denying their success. But I'm also not attributing it to the quality
of their product.

------
pdog
Cool technique, but you hint at the best solution: "running all teams in a
shared context to eliminate the overhead of one webview per team."

~~~
brianwawok
Wouldn't the best solution be write it in C and have the entire app take 20MB
of ram?

~~~
CapacitorSet
I think Slack is focusing on code reuse, eg. using the same HTML/CSS/JS
codebase across all platforms - hence it would be preferrable to avoid having
to compile for every platform.

~~~
kalleboo
I don't think compliation is the issue, it's supporting the diverse platform
APIs and UI toolkits.

~~~
coldtea
They use like 5 widgets (styled text, textfield, buttons, radios, etc). They
could create their own UI toolkit with 1/10 the resources they have.

~~~
joekim
If this is true, then why are even bigger players with more resources like
Facebook and Microsoft building on top of Electron instead of building
natively?

I surmise that you are not alone in believing that Slack would be better built
as a native app. But if it's such a bad direction why are so many going down
this road and what are they missing?

~~~
coldtea
> _If this is true, then why are even bigger players with more resources like
> Facebook and Microsoft building on top of Electron instead of building
> natively?_

Because software is a pop culture, and the latest fad always prevails at most
shops. Also companies care more about cutting corners and shipping sooner than
about the long haul.

That said, it's not like Facebook particularly enjoyed web based apps: "Mark
Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5"

[https://techcrunch.com/2012/09/11/mark-zuckerberg-our-
bigges...](https://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-
mistake-with-mobile-was-betting-too-much-on-html5/)

~~~
joekim
The mistake there was one of timing and approach and they learned from it. The
promise of cross-platform, web-based technology is still there, that's why
they created React Native.

~~~
coldtea
React Native is not web-based. It just uses Javascript.

~~~
joekim
The technology originated from web. It uses javascript, React, babel, flexbox,
etc.

------
mdekkers
why not use the right tool for the job instead of doing Olympic-level
gymnastics to use a hammer as a screwdriver?

~~~
jjnoakes
Because it is faster and cheaper to get a junior JavaScript developer to bang
out a cross platform GUI in electron than it is to get one or more developers
together to write a proper cross-platform native application.

They cared more about cost and time to market than performance and technical
prowess, and in a business context, that is often a correct trade-off.

I don't like it because I prefer small fast clean applications, but I know I'm
in the minority and I accept that that's how the business world works.

~~~
mdekkers
_They cared more about cost and time to market than performance and technical
prowess, and in a business context, that is often a correct trade-off._

Cool when you are starting up and all, but surely they must have a bit more
money now, and would be able to do it right?

~~~
nemothekid
When Facebook was hitting performance issues with PHP, they decided to rewrite
the entire runtime instead of rewriting in a different language.

If Facebook with its billions decided it was cheaper to rewrite PHP, the
cost/benefit analysis must favor optimizing current code than doing a rewrite

~~~
mdekkers
Facebook is Facebook. Slack isn't Facebook, and neither is _every other
business besides Facebook_ Facebook decided to rewrite PHP because the CBA
worked out for _Facebook_ \- that doesn't mean the argument holds true by
default for any other situation.

