optimization isn't always about multi-threading and optimizing hardware utilization. in fact, most performance work is about simply doing less.tantan's video...
That single line of code may be using a slow abstraction, doesn’t cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it’s meant to solve.
More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages… Performance optimizations especially.
A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.
More lines of code = slower
It doesn’t. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable…
It doesn’t. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement.
I was talking about a specific edge case there. The way the scripting system for ARMA is handled, a longer script will take more time to parse and run than a script that can do the same thing in fewer lines, except in some rare instances where you actually could optimize how it’s handling a certain function.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
That single line of code may be using a slow abstraction, doesn’t cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it’s meant to solve.
More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages… Performance optimizations especially.
A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.
It doesn’t. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable…
This makes me feel better about my if…then…else walls.
I was talking about a specific edge case there. The way the scripting system for ARMA is handled, a longer script will take more time to parse and run than a script that can do the same thing in fewer lines, except in some rare instances where you actually could optimize how it’s handling a certain function.