One problem I've noticed with JavaScript functional style is that the most elegant construct doesn't offer the best performance. You'd think that, especially for synchronous stateless arrow functions with single-statement bodies nested within array methods like map, reduce or filter, some kind of analysis similar to that done by RDBMSes on SQL queries could be performed in order to produce the same result faster.
Conversation
Notices
-
🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:07:36 EST 🇳🇴 Thor — backup account
-
🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:11:27 EST 🇳🇴 Thor — backup account
You'll often have a situation where what you're doing is essentially performing a JOIN on two arrays, and it runs slow as balls, because you're running a find() on one array inside of a map() on the other, and it's performing a linear search on the inner array for every entry in the outer array, and that's not necessary.
-
🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:17:18 EST 🇳🇴 Thor — backup account
If you could somehow tell JavaScript that the inner array is sorted by the key you're searching for, and that you're going to be scanning most of the array for results, it could then compile that into a nested loop with two iterators, where the inner loop only performs a search if the elements don't line up.
You could speed up such an algorithm by transforming your inner array into a hash map (associative array), of course...
-
🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:20:14 EST 🇳🇴 Thor — backup account
But here we reach another annoyance I've faced in pretty much every language I've used so far: There is never a multi-key map type or class in the standard library. In relational databases, you can add an index to any column you wish to search. In your average OOP language, you can only index one key... and you can't simultaneously treat that key as a value. A sort of in-memory database table is such a universally useful construct that it should really exist in every language.
-
-
-