5 ms·
Interesting article. One point where I don't totally agree: > programmers should try and write their software in a way that makes reasonable use of the resourc
by Zababa 5y ago
Interesting article. One point where I don't totally agree:
> programmers should try and write their software in a way that makes reasonable use of the resources of the computer.
As programmers, I think we should build tools to help us with that. This kind of article will appeal to people already sensitive to performance, just like talking about software craftsmanship will appeal to people already proud of their job. But if we want to change the industry for the better, we have to enforce that with tools.
Since Rust is used here, we could imagine something like clippy (a linter) but for performance. You could have lots of options, with a few defaults performance levels. For example, at performance level 0 (minimal performance), lines() is fine. At level 1, it could become a warning. At level 2, an error.
The problem I see is that while lines() is easy to fix, the part about Unicode would be harder to do, and that was where most of the performance improvements were found. Maybe that can be fixed at the library level?
- sharikone 5y agoI disagree. Such tooling would probably be annoying for pro users and beginners alike. The reasoning involved is deeper than what an automatic tool can accomplish. It requires knowledge of computers (disk access speed) and of the input (mostly not unicode). We can imagine inputs for which this optimization does not work and also architectures where it will be less effective. This is the kind of reasoning experienced humans are (still) better than machines.
- Zababa 5y ago> The reasoning involved is deeper than what an automatic tool can accomplish. Not for the part where you have to use something else than lines(). It's ~10% of the time spent in the code. As I said, it's not the biggest improvement, but for something that can easily be automated, 10% is great. For the part about unicode, I agree that it's harder to find a solution. Maybe the library for JSON could first check if a \u or \U is in the object, and if so decode it as unicode? I may be missing something here, but that doesn't seem too hard. Of course it would be a bit slower than just decode unicode if everything is unicode. But if the majority of JSON is like the one in this article, this would be a sensible default. For sure, we can't replace humans. That's not the goal. The goal is to offload easy and repetitve tasks to tools, and also to encode tacit knowledge in them.