Why are so many mobile browsers at least 100, if not 200 megabytes in size? Even Firefox Focus which is supposed to be small and, you know, focussed is 85MB big.

The smallest browser I could find was the /e/ Foundation’s built-in browser for /e/OS. It’s 12MB.

It’s kind of between Firefox and Focus in terms of features so why are all other browsers so big? Is there a small version of Firefox for Android?

Edit: I just looked up the /e/ Browser repo on their GitLab and the browser appears to be bigger than the 12MB displayed in App Info. It’s about 70MB, so pretty comparable to the other browsers. I was so confused by the size difference but that’s cleared up now.

  • @[email protected]
    link
    fedilink
    228 months ago

    When it comes to software, complexity usually means one of 2 things: time complexity or space complexity. They have an inverse relationship, so if you want something fast you need more memory, and vice versa. In regards to browsers, that means either waiting forever to execute each op or using large amounts of storage/memory.

    • illectrilityOP
      link
      fedilink
      3
      edit-2
      8 months ago

      Yeah, of course a lot is cached and stored in user data but I don’t get why the app itself has to be so big. It’s not significantly faster.

      Edit: Never mind all that, I edited the post, the app size wasn’t correctly shown.

      • @[email protected]
        link
        fedilink
        13
        edit-2
        8 months ago

        Caching is separate. Honestly, I don’t know how to explain it to you without giving you a college level explanation of time complexity.

        Think about the most basic way to sort a list of arbitrary size; comparing the first item to the second item, swapping if the second item is smaller, and then repeating until no more swaps occur. This has a time complexity of O(n^2), so on a list of n size, it would be extremely cheap on memory (O(1)) but will take a very long time if n is large.

        There’s another sorting algorithm called quicksort that is much faster (how it works isn’t very important atm), with a time complexity of O(nlog n). This is far faster than the other method of sorting, but it comes at the cost of needing a lot more memory to execute the algorithm, O(log n) of space.

        If you scale this simple process to a multithreaded piece of software executing thousands of algorithms per second, like a browser, the size of n scales to the rest of the app. Browsers are generally written in C++, which requires memory to be preallocated. The size of the app includes this memory requirement, as well as the executable.

        • illectrilityOP
          link
          fedilink
          48 months ago

          I understand, my confusion was caused by the misleading app size shown in App Info. It’s actually like 70MB so my question is dumb. I’m sorry for wasting your time

          • @[email protected]
            link
            fedilink
            78 months ago

            it’s not dumb, and you didn’t waste my time! I love teaching computer science to people. Honestly, this was kinda fun. I haven’t consciously thought about these concepts in about 6 years, so it was a good refresher for me too lol

            • illectrilityOP
              link
              fedilink
              68 months ago

              I’m glad to hear that, I had fun, too. Thank you for your time and have an amazing day, kind stranger

        • @[email protected]
          link
          fedilink
          28 months ago

          One time I had a database migration running on a database of about 50gb. After eight hours it was still going.

          My client had the suggestion to try bumping up the memory on the server. So (in digital ocean) I scaled a server from 8gb memory to 64gb, and ran the same migration. It took about twenty seconds. Then just scaled the server back down.

          It’s kinda amazing just how significant efficiency differences can be between strategies. In most realms a 10% improvement is huge. In software a 1000000000% improvement can result from choosing a new strategy.

    • @[email protected]
      link
      fedilink
      38 months ago

      Don’t forget developmental complexity. The real limited resource is developer brain power which is the primary (and legit) reason for most failures to optimize algorithms.

      Sometimes the most optimized solution requires a developer with enormous working memory, who can write code nobody else on the team can follow.

      I worked on an app as a subcontractor once and this guy had functions generating functions to generate functions. It worked, and it was parsimonious in a way. Like he was optimizing for the bundle size and it was pretty impressive, but I simply couldn’t get anything done because the way it was structured required me to hold like 12 chunks of info in my 7-chunk working memory.

      I eventually got some progress but only after I had transferred a significant amount of the code into my long-term memory. (As an autistic my working memory was shit growing up so I learned to use my long term procedural memory as a stand-in for short term memory. Problem is it’s a brittle strategy, doesn’t respond to changes well, and is highly sensitive to what kinds of patterns are used).