3 ms·

> A large part of becoming a decent engineer [2] for me was learning to stop trusting what professors taught me in college When I was taught about performance,

by klyrs 3y ago

> A large part of becoming a decent engineer [2] for me was learning to stop trusting what professors taught me in college When I was taught about performance, it was all about benchmarking and profiling. I never needed to trust what my professors taught, because they taught me to dig in and find the truth for myself. This was taught alongside the big-O stuff, with several examples where "fast" algorithms are slower on small inputs.

TylerE 3y ago
How do you even get meaningful profiling out of most modern langs? It seems the vast majority of time and calls gets spent inside tiny anonymous functions, GC allocations, and stuff like that.
- klyrs 3y ago
  I don't use most modern langs! And especially if I'm doing work where performance is critical, I won't kneecap myself by using a language that I can't reasonably profile.
- neonsunset 3y ago
  This is easy in most modern programming languages. JVM ecosystem has IntelliJ Idea profiler and similar advanced tools (AFAIK). .NET has VS/Rider/dotnet-trace profilers (they are very detailed) to produce flamegraphs. Then there are native profilers which can work with any AOT compiled language that produces canonically symbolicated binaries: Rust, C#/F#(AOT mode), Go, Swift, C++, etc. For example, you can do `samply record ./some_binary`[0] and then explore multi-threaded flamegraph once completed (I use it to profile C#, it's more convenient than dotTrace for preliminary perf work and is usually more than sufficient). [0] https://github.com/mstange/samply https://github.com/mstange/samply
  - TylerE 3y ago
    I mean sure, but I've never seen much in a flamegraph besides noise.
    - neonsunset 3y ago
      My experience is complete opposite. You just need to construct a realistic load test for the code and the bottlenecks will stand out (more often than not). Also there is learning curve to grouping and aggregating data.

by klyrs 3y ago

TylerE 3y ago

How do you even get meaningful profiling out of most modern langs? It seems the vast majority of time and calls gets spent inside tiny anonymous functions, GC allocations, and stuff like that.

klyrs 3y ago
I don't use most modern langs! And especially if I'm doing work where performance is critical, I won't kneecap myself by using a language that I can't reasonably profile.
neonsunset 3y ago
This is easy in most modern programming languages. JVM ecosystem has IntelliJ Idea profiler and similar advanced tools (AFAIK). .NET has VS/Rider/dotnet-trace profilers (they are very detailed) to produce flamegraphs. Then there are native profilers which can work with any AOT compiled language that produces canonically symbolicated binaries: Rust, C#/F#(AOT mode), Go, Swift, C++, etc. For example, you can do `samply record ./some_binary`[0] and then explore multi-threaded flamegraph once completed (I use it to profile C#, it's more convenient than dotTrace for preliminary perf work and is usually more than sufficient). [0] https://github.com/mstange/samply https://github.com/mstange/samply
- TylerE 3y ago
  I mean sure, but I've never seen much in a flamegraph besides noise.
  - neonsunset 3y ago
    My experience is complete opposite. You just need to construct a realistic load test for the code and the bottlenecks will stand out (more often than not). Also there is learning curve to grouping and aggregating data.