8 ms·

Reducing Slack’s memory footprint

48 points by cpeterso 10y ago

pdog 10y ago
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 10y ago
  Wouldn't the best solution be write it in C and have the entire app take 20MB of ram?
  - deleted 10y ago
    [deleted]
  - pjmlp 10y ago
    Yes, it is incredible the amount of gimmicks web devs do instead of using the right tools for native development.
    - joekim 10y ago
      Could you elaborate on what you think the elaborate on what the "right" tools would be?
      - pjmlp 10y ago
        Write in native languages, common to all platforms, using the OS specific APIs in each platform with the help on an abstraction layer. Lets pick C++ as an example of native language. Design the application architecture with the abstract ideas of what should be available across all platforms, but keeping in mind the native idioms. For each of such concepts, provide an interface (pure abstract classes in C++ speak) with an implementation for each OS. The actual cpp files are selected during the build process according to the OS being compiled, without any kind of #ifdefs. Then showing a notification to the user using this architecture is as simple as. auto notification = NotificationService.instance(); notification->show("New email available!"); Or opening a file, using the platform specific file dialogs: auto filePicker = Pickers.file_instance() auto filename = filePicker->open_file(); This are just two basic examples, the idea is not to replicate Qt, wxWidgets, JUCE,... rather pick just the concepts required for the application, not to build a full blown framework. This is the approach taken by quite a few companies. Of course, there is also the shortcut of using something like Qt, but then you need to live with the problem that the widgets aren't native, rather emulated. On the other hand, still outperforms any browser based application. The craziness with Electron based apps isn't nothing new to us oldies. Since the early days of the web, OSes have supported web widgets like MSHTML on Windows, Windows packaged Web Applications introduced on Windows Active Desktop, Mozilla's XUL and many others. They were never a match to native UI/UX.
  - CapacitorSet 10y ago
    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 10y ago
      I don't think compliation is the issue, it's supporting the diverse platform APIs and UI toolkits.
      - coldtea 10y ago
        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.
        pjmlp 10y ago
        Apparently for the web dev generation, writing modular native code across OSes is a lost art, attained by us old druids not worth listening to.
        coldtea 10y ago
        Yeah, and it's especially puzzling since they've given up one of the major hassles of going natively cross-platform anyway: having to support a native look and feel. Which makes creating a similar (uniform looking across platforms) native UI lib even easier than catering to the intricacies of each platform.
        joekim 10y ago
        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?
  - deleted 10y ago
    [deleted]
mdekkers 10y ago
why not use the right tool for the job instead of doing Olympic-level gymnastics to use a hammer as a screwdriver?
- coldtea 10y ago
  Because Electron (or whatever they use) is web-scale.
  - mdekkers 10y ago
    Because Electron (or whatever they use) is web-scale. Web-scale? What's web scale? why does my desktop client need to be "web-scale"?
    - coldtea 10y ago
      Everything needs to be web-scale: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
      - mdekkers 10y ago
        That's hilarious
      - paulddraper 10y ago
        /dev/null is web-scale http://engineering.wayfair.com/2013/04/devnull-vs-mongodb-benchmark-bake-off/ http://engineering.wayfair.com/2013/04/devnull-vs-mongodb-be...
- thunder-ltu 10y ago
  This.
- jjnoakes 10y ago
  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.
bborud 10y ago
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 10y ago
  And yet Slack runs just fine on my 2016 12" MacBook, iPhone 7 Plus, and iPad Mini 4.
  - coldtea 10y ago
    "...with a single team of 5 and 2 channels". Seriously, it's not about "running just fine", it's about how many resources it uses. Even the startup time is awful for what it does. And the Slack team itself recognizes that there are issues -- as seen in TFA: "However, these capabilities come at a cost: the desktop client can use a lot of memory. This memory footprint increases as the user signs into more teams, as each team runs in its own webview. More memory usage means worse performance, degrading our customer’s experience of Slack and their other applications." and: "At the time of writing, about 36% of active Slack users are signed into more than one team in the desktop app. 17% are signed into 3 or more teams, and 5% are signed into 5 or more teams. Each of these teams is running the full JavaScript web application and maintaining and updating the DOM tree as the state of the team changes. This application can consume between ~130MB (p10) and ~960MB (p99) of memory depending on team activity and UI state."
  - bborud 10y ago
    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.
deleted 10y ago
[deleted]

48 points by cpeterso 10y ago

pdog 10y ago

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 10y ago
Wouldn't the best solution be write it in C and have the entire app take 20MB of ram?
- deleted 10y ago
  [deleted]
- pjmlp 10y ago
  Yes, it is incredible the amount of gimmicks web devs do instead of using the right tools for native development.
  - joekim 10y ago
    Could you elaborate on what you think the elaborate on what the "right" tools would be?
    - pjmlp 10y ago
      Write in native languages, common to all platforms, using the OS specific APIs in each platform with the help on an abstraction layer. Lets pick C++ as an example of native language. Design the application architecture with the abstract ideas of what should be available across all platforms, but keeping in mind the native idioms. For each of such concepts, provide an interface (pure abstract classes in C++ speak) with an implementation for each OS. The actual cpp files are selected during the build process according to the OS being compiled, without any kind of #ifdefs. Then showing a notification to the user using this architecture is as simple as. auto notification = NotificationService.instance(); notification->show("New email available!"); Or opening a file, using the platform specific file dialogs: auto filePicker = Pickers.file_instance() auto filename = filePicker->open_file(); This are just two basic examples, the idea is not to replicate Qt, wxWidgets, JUCE,... rather pick just the concepts required for the application, not to build a full blown framework. This is the approach taken by quite a few companies. Of course, there is also the shortcut of using something like Qt, but then you need to live with the problem that the widgets aren't native, rather emulated. On the other hand, still outperforms any browser based application. The craziness with Electron based apps isn't nothing new to us oldies. Since the early days of the web, OSes have supported web widgets like MSHTML on Windows, Windows packaged Web Applications introduced on Windows Active Desktop, Mozilla's XUL and many others. They were never a match to native UI/UX.
- CapacitorSet 10y ago
  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 10y ago
    I don't think compliation is the issue, it's supporting the diverse platform APIs and UI toolkits.
    - coldtea 10y ago
      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.
      - pjmlp 10y ago
        Apparently for the web dev generation, writing modular native code across OSes is a lost art, attained by us old druids not worth listening to.
        coldtea 10y ago
        Yeah, and it's especially puzzling since they've given up one of the major hassles of going natively cross-platform anyway: having to support a native look and feel. Which makes creating a similar (uniform looking across platforms) native UI lib even easier than catering to the intricacies of each platform.
      - joekim 10y ago
        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?
- deleted 10y ago
  [deleted]

mdekkers 10y ago

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

coldtea 10y ago
Because Electron (or whatever they use) is web-scale.
- mdekkers 10y ago
  Because Electron (or whatever they use) is web-scale. Web-scale? What's web scale? why does my desktop client need to be "web-scale"?
  - coldtea 10y ago
    Everything needs to be web-scale: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
    - mdekkers 10y ago
      That's hilarious
    - paulddraper 10y ago
      /dev/null is web-scale http://engineering.wayfair.com/2013/04/devnull-vs-mongodb-benchmark-bake-off/ http://engineering.wayfair.com/2013/04/devnull-vs-mongodb-be...
thunder-ltu 10y ago
This.
jjnoakes 10y ago
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.

bborud 10y ago

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 10y ago
And yet Slack runs just fine on my 2016 12" MacBook, iPhone 7 Plus, and iPad Mini 4.
- coldtea 10y ago
  "...with a single team of 5 and 2 channels". Seriously, it's not about "running just fine", it's about how many resources it uses. Even the startup time is awful for what it does. And the Slack team itself recognizes that there are issues -- as seen in TFA: "However, these capabilities come at a cost: the desktop client can use a lot of memory. This memory footprint increases as the user signs into more teams, as each team runs in its own webview. More memory usage means worse performance, degrading our customer’s experience of Slack and their other applications." and: "At the time of writing, about 36% of active Slack users are signed into more than one team in the desktop app. 17% are signed into 3 or more teams, and 5% are signed into 5 or more teams. Each of these teams is running the full JavaScript web application and maintaining and updating the DOM tree as the state of the team changes. This application can consume between ~130MB (p10) and ~960MB (p99) of memory depending on team activity and UI state."
- bborud 10y ago
  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.

deleted 10y ago

[deleted]