6 ms·

Made some offhanded comment about Chrome perf on Twitter earlier this year and a Google friend replied something like "Well, pretty much the whole Chrome team j

by cududa 4y ago

Made some offhanded comment about Chrome perf on Twitter earlier this year and a Google friend replied something like "Well, pretty much the whole Chrome team just got upgraded to local test machines with at least 32gb of RAM. Godspeed everyone."

q7xvh97o2pDhNrh 4y ago
Makes you wonder what would happen if companies occasionally did the exact opposite to their engineers. "Oh, you know that 32 GB machine you've got? We're replacing it with this new 16 GB one. If the test suite is too slow on your new machine, I guess you'll just have to make the tests faster."
- Our_Benefactors 4y ago
  What would happen is those engineers would rightly be concerned that their leadership had lost their marbles, and would quickly find new jobs elsewhere. These kinds of “fun” thought experiments don’t pan out in the real world.
  - cududa 4y ago
    You having fun/ being able to develop fast isn't your customer's problem/ the problem's of people actually using the things you build. Windows Vista devs with 8GB of DDR2 when real world customers had 512mb of DDR learned this lesson hard. EDIT: Also - client side native software and web dev are insanely different. Web/ serverside people seem to disregard this. Constantly.
    - Our_Benefactors 4y ago
      > You having fun/ being able to develop fast isn't your customer's problem/ the problem's of people actually using the things you build. I cannot parse this sentence. What does vista having its minimum requirements poorly defined have to do with being forced to develop on underpowered hardware? If my boss says “we are giving you a worse machine because we think that will make you write better code” I am out of there. There are plenty of ways to emulate weaker hardware and do performance testing and to make it a development priority that don’t involve intentionally hamstringing your engineers.
      - cududa 4y ago
        Tell me you've never developed native applications outside an iOS simulator, or OS development without telling me...
        Our_Benefactors 4y ago
        Do you actually have something to add to the discussion? Or you just want to take potshots at me? You’re all over the place. Please explain why you think using underpowered hardware is the only legitimate way to write software that works on that hardware.
        cududa 4y ago
        Yes, I started this discussion thread you're responding to. No, there isn't really a way to do native development without experiencing what your customers do. Build locally on the high powered one, run on your lower spec'd machine. This isn't a potshot. This is me being annoyed that 15 years later, people keep making the same mistakes of not testing on "real world" hardware. Your VM isn't a real user representation. Stop thinking so.
        hinkley 4y ago
        I think the problem is the either or nature. One dev one box is a mistake. The team should have a few they share. In particular I often fight the slowest machine leaving the office. That should stay for a long time, set aside for testing.
        giantrobot 4y ago
        You can write your code on a nice fast machine. A dev machine should be as fast as possible. Those devs with their big fast machines should be required to run and test on much lower spec machines though. Testing only in a VM on a beefy dev box leads to terribly performing software on customer machines. There's a multitude of performance problems that only come up when a system starts paging to disk, a machine has a HDD, or a CPU gets maxed out. These issues will be completely occulted on a dev machine with tons of RAM, 16 cores, and an NVMe disk. Far too many developers have the beefy dev box with no requirements to test on more prosaic configurations. Even limiting a VM's CPU and memory isn't a good environment for performance testing because it's still faster than actual low end hardware.
  - copperx 4y ago
    It's a matter of tact. They could say, "Here are your 32GB RAM machines. Your old one? You get to keep it too. Make sure Chrome works perfectly on your old machine."
    - cududa 4y ago
      This is how it should go. Not setting the high perf machine as a benchmark.
  - Pelam 4y ago
    At least not every engineer. I love using older machines and any chance to make things work in a hardware friendly way. I have to say, I appreciate the insane expertise browser engine developers have in making JS and layouting run fast.
- mhh__ 4y ago
  This is what CI can be used for
- ip26 4y ago
  You’d have less fallout if you just delay giving them upgrades long past the point they are due.
- ayewo 4y ago
  This is what CI (Continuous Integration) and CD (Continuous Delivery) systems were designed for. If certain tests exceed the performance budget of a low-resource environment in CI/CD, the engineer responsible will be required to fix it before a release can ship.
calderwoodra 4y ago
32gb is hilariously low for Google, my machine has 196gb of ram.
- cududa 4y ago
  bragging about having 196GB in a thread about real world performance is exactly why this thread happened
  - calderwoodra 4y ago
    Wasn't meant to be a brag, just letting you know that 32gb of ram is on the low end for most employees.
  - vkou 4y ago
    No, this thread happened because not enough effort was put into automating performance testing. Which, unlike making everyone develop on palm-pilots, is the correct solution to performance problems.
- ahartmetz 4y ago
  I can tell from the build time memory requirement of Blink.

by cududa 4y ago

q7xvh97o2pDhNrh 4y ago

Makes you wonder what would happen if companies occasionally did the exact opposite to their engineers. "Oh, you know that 32 GB machine you've got? We're replacing it with this new 16 GB one. If the test suite is too slow on your new machine, I guess you'll just have to make the tests faster."

Our_Benefactors 4y ago
What would happen is those engineers would rightly be concerned that their leadership had lost their marbles, and would quickly find new jobs elsewhere. These kinds of “fun” thought experiments don’t pan out in the real world.
- cududa 4y ago
  You having fun/ being able to develop fast isn't your customer's problem/ the problem's of people actually using the things you build. Windows Vista devs with 8GB of DDR2 when real world customers had 512mb of DDR learned this lesson hard. EDIT: Also - client side native software and web dev are insanely different. Web/ serverside people seem to disregard this. Constantly.
  - Our_Benefactors 4y ago
    > You having fun/ being able to develop fast isn't your customer's problem/ the problem's of people actually using the things you build. I cannot parse this sentence. What does vista having its minimum requirements poorly defined have to do with being forced to develop on underpowered hardware? If my boss says “we are giving you a worse machine because we think that will make you write better code” I am out of there. There are plenty of ways to emulate weaker hardware and do performance testing and to make it a development priority that don’t involve intentionally hamstringing your engineers.
    - cududa 4y ago
      Tell me you've never developed native applications outside an iOS simulator, or OS development without telling me...
      - Our_Benefactors 4y ago
        Do you actually have something to add to the discussion? Or you just want to take potshots at me? You’re all over the place. Please explain why you think using underpowered hardware is the only legitimate way to write software that works on that hardware.
        cududa 4y ago
        Yes, I started this discussion thread you're responding to. No, there isn't really a way to do native development without experiencing what your customers do. Build locally on the high powered one, run on your lower spec'd machine. This isn't a potshot. This is me being annoyed that 15 years later, people keep making the same mistakes of not testing on "real world" hardware. Your VM isn't a real user representation. Stop thinking so.
        hinkley 4y ago
        I think the problem is the either or nature. One dev one box is a mistake. The team should have a few they share. In particular I often fight the slowest machine leaving the office. That should stay for a long time, set aside for testing.
        giantrobot 4y ago
        You can write your code on a nice fast machine. A dev machine should be as fast as possible. Those devs with their big fast machines should be required to run and test on much lower spec machines though. Testing only in a VM on a beefy dev box leads to terribly performing software on customer machines. There's a multitude of performance problems that only come up when a system starts paging to disk, a machine has a HDD, or a CPU gets maxed out. These issues will be completely occulted on a dev machine with tons of RAM, 16 cores, and an NVMe disk. Far too many developers have the beefy dev box with no requirements to test on more prosaic configurations. Even limiting a VM's CPU and memory isn't a good environment for performance testing because it's still faster than actual low end hardware.
- copperx 4y ago
  It's a matter of tact. They could say, "Here are your 32GB RAM machines. Your old one? You get to keep it too. Make sure Chrome works perfectly on your old machine."
  - cududa 4y ago
    This is how it should go. Not setting the high perf machine as a benchmark.
- Pelam 4y ago
  At least not every engineer. I love using older machines and any chance to make things work in a hardware friendly way. I have to say, I appreciate the insane expertise browser engine developers have in making JS and layouting run fast.
mhh__ 4y ago
This is what CI can be used for
ip26 4y ago
You’d have less fallout if you just delay giving them upgrades long past the point they are due.
ayewo 4y ago
This is what CI (Continuous Integration) and CD (Continuous Delivery) systems were designed for. If certain tests exceed the performance budget of a low-resource environment in CI/CD, the engineer responsible will be required to fix it before a release can ship.

calderwoodra 4y ago

32gb is hilariously low for Google, my machine has 196gb of ram.

cududa 4y ago
bragging about having 196GB in a thread about real world performance is exactly why this thread happened
- calderwoodra 4y ago
  Wasn't meant to be a brag, just letting you know that 32gb of ram is on the low end for most employees.
- vkou 4y ago
  No, this thread happened because not enough effort was put into automating performance testing. Which, unlike making everyone develop on palm-pilots, is the correct solution to performance problems.
ahartmetz 4y ago
I can tell from the build time memory requirement of Blink.