This forum seems to be quite annoying, people coming up with their hypothetical flaws in other people's arguments and glaring generalizations. You seem to be hinting that "if you don't know how string literals work in C your app is going to be bloated and have poor performance". That's simply garbage.
I quite specifically said you should focus on the important bits, and performance, scalability, good code quality and such are much more important than the low level internals of a programming language. These problems are generally solved at a MUCH higher level on the architectural design, except in a very few special cases.
In case of apps proper use of concurrency models and such is much more likely to affect your performance, than finding the most optimal way to handle strings. Similarly in the web it doesn't matter if your request takes a few more CPU cycles to complete if the architecture is solid and the system scales well to incoming traffic.
No, I literally never have to know the low level details of how strings are implemented in language X to know that it is more than likely unrelated to any performance issues I might be facing.
For example you don't have to know the low level details of how strings are implemented to know that loading a 2GB text file directly in RAM and trying to process it is not quite as efficient than processing it in small chunks.
You definitely do not need to know the low level details of C strings to know which bits are the important bits for you to focus on, unless you're working on some very low level implementations using C strings, and most people aren't.
That was merely one example. There are plenty of others. One is some developer was putting expensive function calls as arguments to a debug print function, so even when the debug printing was disabled, the function arguments were still being called (and their results discarded). In this case, he obviously didn't know that function arguments are always evaluated. That's a fairly low-level thing, but it can kill your performance.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This forum seems to be quite annoying, people coming up with their hypothetical flaws in other people's arguments and glaring generalizations. You seem to be hinting that "if you don't know how string literals work in C your app is going to be bloated and have poor performance". That's simply garbage.
I quite specifically said you should focus on the important bits, and performance, scalability, good code quality and such are much more important than the low level internals of a programming language. These problems are generally solved at a MUCH higher level on the architectural design, except in a very few special cases.
In case of apps proper use of concurrency models and such is much more likely to affect your performance, than finding the most optimal way to handle strings. Similarly in the web it doesn't matter if your request takes a few more CPU cycles to complete if the architecture is solid and the system scales well to incoming traffic.
No, I literally never have to know the low level details of how strings are implemented in language X to know that it is more than likely unrelated to any performance issues I might be facing.
For example you don't have to know the low level details of how strings are implemented to know that loading a 2GB text file directly in RAM and trying to process it is not quite as efficient than processing it in small chunks.
Nobody is putting a gun to your head either to read it or reply. If it's that annoying to you, stop.
And I quite specifically said you have to know a breadth of things to know which bits are the important bits.
You definitely do not need to know the low level details of C strings to know which bits are the important bits for you to focus on, unless you're working on some very low level implementations using C strings, and most people aren't.
That was merely one example. There are plenty of others. One is some developer was putting expensive function calls as arguments to a debug print function, so even when the debug printing was disabled, the function arguments were still being called (and their results discarded). In this case, he obviously didn't know that function arguments are always evaluated. That's a fairly low-level thing, but it can kill your performance.