Jonkman Microblog
  • Login
Show Navigation
  • Public

    • Public
    • Network
    • Groups
    • Popular
    • People

Conversation

Notices

  1. 🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:07:36 EST 🇳🇴 Thor — backup account 🇳🇴 Thor — backup account

    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.

    In conversation Tuesday, 06-Nov-2018 23:07:36 EST from octodon.social permalink
    1. 🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:11:27 EST 🇳🇴 Thor — backup account 🇳🇴 Thor — backup account
      in reply to

      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.

      In conversation Tuesday, 06-Nov-2018 23:11:27 EST from octodon.social permalink
      1. 🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:17:18 EST 🇳🇴 Thor — backup account 🇳🇴 Thor — backup account
        in reply to

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

        In conversation Tuesday, 06-Nov-2018 23:17:18 EST from octodon.social permalink
        1. 🇳🇴 Thor — backup account (thorthenorseman@octodon.social)'s status on Tuesday, 06-Nov-2018 23:20:14 EST 🇳🇴 Thor — backup account 🇳🇴 Thor — backup account
          in reply to

          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.

          In conversation Tuesday, 06-Nov-2018 23:20:14 EST from octodon.social permalink
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

Jonkman Microblog is a social network, courtesy of SOBAC Microcomputer Services. It runs on GNU social, version 1.2.0-beta5, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All Jonkman Microblog content and data are available under the Creative Commons Attribution 3.0 license.

Switch to desktop site layout.