23 ms·

Very interesting, and great work contributing to the open source community! Can you elaborate on how you did the profiling to identify the (potentially) slow p

Very interesting, and great work contributing to the open source community! Can you elaborate on how you did the profiling to identify the (potentially) slow parts?

llanowarelves 4y ago
Yes this would be helpful. JavaScript programmers, in my experience, don't really use profilers like "traditional" programmers do. Maybe it's as much the tooling as it is the culture?
- chii 4y ago
  The profiler in chrome is pretty good, and can be used fairly easily for both frontend and backend profiling. If said programmer doesn't use it, it's because they lack engineering maturity and competency.
  - brundolf 4y ago
    > it's because they lack engineering maturity and competency There's no need to escalate into personal attacks. Chrome's JS profiler is great, and is perfect for the kind of thing the OP is doing. But it's very rare that CPU cycles are a material problem in customer-facing JavaScript code, and it would be easy to get quite a few years into a career without ever getting exposure to it. I've had exactly one (very unusual) job where I used it frequently. The rest of the time, it pretty much collects dust.
    - spoils19 4y ago
      It's a reflection of their experience and tenure as a programmer, not a personal attack. The fact that it applies to most, if not all, JavaScript developers is a coincidence.
      - brundolf 4y ago
        And I wouldn't fault a senior engineer's competency for not being familiar with JS profiling. Like I said, you could easily have a decade's worth of front-end jobs without it ever becoming relevant.
    - hinkley 4y ago
      Profilers also lie. Learning the ways in which they are wrong is its own skillset, and the current generation of profilers is missing bits of critical information. Which means that not only do users misunderstand the value of profiling data, so do the profiler writers. If the writers can't get it right, good fucking luck to someone with 3 years of programming experience.
      - jansan 4y ago
        > Profilers also lie Yep, it becomes obvious when the Chrome profiler tells you that the CPU has spent a sizable amount of time on a javascript comment, which it sometimes actually does.
      - maccard 4y ago
        I've done a lot of profiling over the years, and you're right. In my experience though, it is correct _enough_ in the vast majority of cases to be able to gain significant speedups. You're not going to be eeking cache misses out of your hot paths without understanding what you're looking at, but you will find things like "We spend more time converting to strings and back than we do actually compressing" or "we're spending 100ms of every request loading a config file from S3 that could be cached". If we eliminated the low hanging fruit in some of our most used tools, the difference would be significant.
        hinkley 4y ago
        This may be controversial but I now believe that flame charts are hurting more than helping. These charts are meant to display problems with sequential code, but they end up obfuscating problems with asynchronous code. The evolution toward async-await semantics in Javascript and other languages is 'breaking' current generation profilers. And this is controversial, but also true: 'low-hanging fruit' is death by a thousand cuts. It's a hill climbing algorithm and as we have all known, for generations, that greedy algorithms get stuck in local maxima. And if you know anything about farming, only amateurs pick the low-hanging fruit. Real growers harvest an entire tree at a time, otherwise you waste a ton of fruit. Going module by module instead of chopping off tall tent poles lets you achieve much better results. One of the complaints of the Premature Optimization crowd is the potential for regressions in making changes to code that already 'works'. Refactoring reduces that possibility quite a bit. Module- or Concern-Oriented optimization mops up a lot of the rest. You can get better QA fidelity when making 10 changes in one area of functionality than you can by limiting yourself to 4 but spread across the code base. Why I think more people don't use it, 1) I seem to be the sole proponent, 2) it cuts both ways regarding Instant Gratification. You will know about large problems that you aren't fixing until later. Later answers are often better answers. And on the other edge, it also gets to a bunch of short tent poles that will never make it out of the backlog later in the project. Nobody is going to give you permission to go around making 0.5% performance improvements, and it's a lot of wear and tear to do such work off the books. This is the death by 1000 cuts failure mode. I think the last time I saw someone bragging about a < 1% improvement was the compressed pointer discussion in the V8 blog. I can't even remember the previous example. You can deliver a 16% improvement in one concern instead of the 13% you get from the biggest wins, at very little additional cost or risk. You can keep doing that quarter after quarter, for years, and at the end you've gotten 25% farther than you would have by going the 'easy' route. 25% doesn't matter until it does. Inflection points tear up your project roadmap and disrupt plans. They force (risky) architectural changes farther up in the backlog, and without the benefit of these other little changes you've done along the way, because the best performance improvements also improve code quality, making other changes easier, not harder.
- deleted 4y ago
  [deleted]
mhagemeister 4y ago
Author here. I mainly used node's `--cpu-prof` flag to generate a profile. Tried loading the trace into Chrome DevTools at first, but wasn't able to load the file supposedly because they are too big. So I used https://www.speedscope.app/ https://www.speedscope.app/ instead and which loaded them without any issues and is very snappy overall. What's more is that it allows you to display a left-heavy flamegraph which makes it much easier to spot functions taking up a lot of time. Speedscope is an amazing tool! For webpack based projects the traces were missing quite a bit of data and I had more luck with their own profiling plugin: https://webpack.js.org/plugins/profiling-plugin/ https://webpack.js.org/plugins/profiling-plugin/
- semiquaver 4y ago
  Speedscope is the best.
- romellem 4y ago
  Awesome, thanks! I too have found Chrome's profiler lacking, so will definitely have to check out https://www.speedscope.app/ https://www.speedscope.app/.

Very interesting, and great work contributing to the open source community! Can you elaborate on how you did the profiling to identify the (potentially) slow parts?

llanowarelves 4y ago

Yes this would be helpful. JavaScript programmers, in my experience, don't really use profilers like "traditional" programmers do. Maybe it's as much the tooling as it is the culture?

chii 4y ago
The profiler in chrome is pretty good, and can be used fairly easily for both frontend and backend profiling. If said programmer doesn't use it, it's because they lack engineering maturity and competency.
- brundolf 4y ago
  > it's because they lack engineering maturity and competency There's no need to escalate into personal attacks. Chrome's JS profiler is great, and is perfect for the kind of thing the OP is doing. But it's very rare that CPU cycles are a material problem in customer-facing JavaScript code, and it would be easy to get quite a few years into a career without ever getting exposure to it. I've had exactly one (very unusual) job where I used it frequently. The rest of the time, it pretty much collects dust.
  - spoils19 4y ago
    It's a reflection of their experience and tenure as a programmer, not a personal attack. The fact that it applies to most, if not all, JavaScript developers is a coincidence.
    - brundolf 4y ago
      And I wouldn't fault a senior engineer's competency for not being familiar with JS profiling. Like I said, you could easily have a decade's worth of front-end jobs without it ever becoming relevant.
  - hinkley 4y ago
    Profilers also lie. Learning the ways in which they are wrong is its own skillset, and the current generation of profilers is missing bits of critical information. Which means that not only do users misunderstand the value of profiling data, so do the profiler writers. If the writers can't get it right, good fucking luck to someone with 3 years of programming experience.
    - jansan 4y ago
      > Profilers also lie Yep, it becomes obvious when the Chrome profiler tells you that the CPU has spent a sizable amount of time on a javascript comment, which it sometimes actually does.
    - maccard 4y ago
      I've done a lot of profiling over the years, and you're right. In my experience though, it is correct _enough_ in the vast majority of cases to be able to gain significant speedups. You're not going to be eeking cache misses out of your hot paths without understanding what you're looking at, but you will find things like "We spend more time converting to strings and back than we do actually compressing" or "we're spending 100ms of every request loading a config file from S3 that could be cached". If we eliminated the low hanging fruit in some of our most used tools, the difference would be significant.
      - hinkley 4y ago
        This may be controversial but I now believe that flame charts are hurting more than helping. These charts are meant to display problems with sequential code, but they end up obfuscating problems with asynchronous code. The evolution toward async-await semantics in Javascript and other languages is 'breaking' current generation profilers. And this is controversial, but also true: 'low-hanging fruit' is death by a thousand cuts. It's a hill climbing algorithm and as we have all known, for generations, that greedy algorithms get stuck in local maxima. And if you know anything about farming, only amateurs pick the low-hanging fruit. Real growers harvest an entire tree at a time, otherwise you waste a ton of fruit. Going module by module instead of chopping off tall tent poles lets you achieve much better results. One of the complaints of the Premature Optimization crowd is the potential for regressions in making changes to code that already 'works'. Refactoring reduces that possibility quite a bit. Module- or Concern-Oriented optimization mops up a lot of the rest. You can get better QA fidelity when making 10 changes in one area of functionality than you can by limiting yourself to 4 but spread across the code base. Why I think more people don't use it, 1) I seem to be the sole proponent, 2) it cuts both ways regarding Instant Gratification. You will know about large problems that you aren't fixing until later. Later answers are often better answers. And on the other edge, it also gets to a bunch of short tent poles that will never make it out of the backlog later in the project. Nobody is going to give you permission to go around making 0.5% performance improvements, and it's a lot of wear and tear to do such work off the books. This is the death by 1000 cuts failure mode. I think the last time I saw someone bragging about a < 1% improvement was the compressed pointer discussion in the V8 blog. I can't even remember the previous example. You can deliver a 16% improvement in one concern instead of the 13% you get from the biggest wins, at very little additional cost or risk. You can keep doing that quarter after quarter, for years, and at the end you've gotten 25% farther than you would have by going the 'easy' route. 25% doesn't matter until it does. Inflection points tear up your project roadmap and disrupt plans. They force (risky) architectural changes farther up in the backlog, and without the benefit of these other little changes you've done along the way, because the best performance improvements also improve code quality, making other changes easier, not harder.
deleted 4y ago
[deleted]

mhagemeister 4y ago

Author here. I mainly used node's `--cpu-prof` flag to generate a profile. Tried loading the trace into Chrome DevTools at first, but wasn't able to load the file supposedly because they are too big. So I used https://www.speedscope.app/ https://www.speedscope.app/ instead and which loaded them without any issues and is very snappy overall. What's more is that it allows you to display a left-heavy flamegraph which makes it much easier to spot functions taking up a lot of time. Speedscope is an amazing tool! For webpack based projects the traces were missing quite a bit of data and I had more luck with their own profiling plugin: https://webpack.js.org/plugins/profiling-plugin/ https://webpack.js.org/plugins/profiling-plugin/

semiquaver 4y ago
Speedscope is the best.
romellem 4y ago
Awesome, thanks! I too have found Chrome's profiler lacking, so will definitely have to check out https://www.speedscope.app/ https://www.speedscope.app/.