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.
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.