3 ms·

> "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 m

by joekim 10y ago

> "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 10y ago
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 10y ago
  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 10y ago
    I'm not denying their success. But I'm also not attributing it to the quality of their product.

by joekim 10y ago

bborud 10y ago

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 10y ago
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 10y ago
  I'm not denying their success. But I'm also not attributing it to the quality of their product.