Timeline for How to avoid hidden performance problems in functional interfaces?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 10, 2023 at 23:27 | history | edited | kaya3 | CC BY-SA 4.0 |
deleted 37 characters in body
|
| Jun 19, 2023 at 14:37 | vote | accept | Bbrk24 | ||
| Jun 16, 2023 at 23:51 | answer | added | Bruce Adams | timeline score: 3 | |
| Jun 16, 2023 at 23:16 | history | edited | kaya3 | CC BY-SA 4.0 |
edited title
|
| Jun 16, 2023 at 21:35 | comment | added | kaya3 | The more expressive the language, the easier it is to also express suboptimal solutions, and the real solution is education ─ programmers must learn to identify accidental quadratic behaviour and other performance bugs, by understanding what happens "under the hood" when they use declarative features of the language. Perhaps automated warnings when certain operations like string or list concatenation are used in a loop could help; some linters already do this. I would count that under education, though, since it doesn't involve changing the design of the operations themselves. | |
| Jun 16, 2023 at 21:32 | comment | added | kaya3 | I am not sure any satisfying answer is possible; the more a language lets the programmer describe what the result should be rather than exactly how it should be computed, the more opportunities for performance bugs where the programmer didn't realise that the result they asked for would be computed in a suboptimal way. The ultimate answer is to write imperative instead of declarative code, so the programmer is in control of how results are computed and hence what the performance characteristics of their code are. But this sacrifices too much expressiveness to be a good trade-off, usually. | |
| Jun 16, 2023 at 19:02 | comment | added | Bbrk24 |
@Gilles'SO-stopbeingevil' I was thinking of the more general idea, but I used this example specifically because of the reaction I've gotten when I bring it up. I considered linking to the example from the proposal for count(where:) as well, but ultimately decided not to because the problem mentioned there is O(n) either way.
|
|
| Jun 16, 2023 at 18:09 | comment | added | Gilles 'SO- stop being evil' | I'm not sure the question has a narrow enough scope to be answerable. Please edit it (especially the title) to clarify what you expect: specifically concatenation patterns? Iterate/reduce patterns? Or more generally potentially surprising performance? | |
| Jun 16, 2023 at 18:07 | comment | added | Gilles 'SO- stop being evil' | A lot of languages have similar n² behavior in their standard library. It's not specific to functional interfaces. It's a classic when concatenating strings in Java (among others), for example. Anybody who's “appalled” about this has probably not paid attention to their favorite language. | |
| Jun 16, 2023 at 13:38 | history | asked | Bbrk24 | CC BY-SA 4.0 |