Comments are: it’s to be expected

  • best_username_ever@sh.itjust.works
    3·
    3 months ago

    200 MB modern application built on top of Chrome can’t handle a few files.

    Emacs from the 70/80s can handle a thousand files. Something is wrong with computers.

    • mycodesucks@lemmy.world
      2·
      3 months ago

      Nothing is wrong with computers. Something is wrong with developers.

      “You WILL accept our defined use cases for you. We aren’t interested in writing robust software. We’re interested in writing it badly in 2 days so we can spend the rest of the money on marketing.”

      • SpaceNoodle@lemmy.world
        1·
        3 months ago

        I’m sure most developers would prefer spending the necessary time to write something good. The problem is perverse incentives in the corporate model.

        • mycodesucks@lemmy.world
          0·
          3 months ago

          Sure, for normal software on a real platform. But in mobile it’s often small startups, which means this is explicitly what they WANT.

            • mycodesucks@lemmy.world
              1·
              3 months ago

              At a small enough company they’re often the same thing.

              Also, on mobile, developers who make good, reliable, robust software are discouraged from making such things. There’s a reason there are so few pieces of “finished” software on mobile. Because you’ll invest months of your life into making an incredibly useful and functional tool, and a year later, the new version of the mobile OS will come out, and it’ll be “In the new version we’ve decided half of the operating system calls your software depends on are insecure, and three of the permissions that are necessary for your app to work no longer exist. Have fun rewriting the entire thing”, after which the developer very reasonably says to hell with it, and goes back to writing software for an ecosystem that doesn’t break every single user space application on a regular basis.

              So yes, just by working in the mobile space, you’re already accepting trade-offs in making robust software by the very nature of the ecosystem.

    • arcosenautic@lemmy.world
      1·
      3 months ago

      This. I also wonder when people will realize that having more RAM doesn’t mean having to use it all (electron, looking at you)

      • Vik@lemmy.worldEnglish
        0·
        3 months ago

        I think most operating systems today are designed to make opportunistic use of available RAM but also fuck electron

            • Ephera@lemmy.ml
              0·
              3 months ago

              That’s a different mechanism. A “page” is just a fixed-size portion of memory, e.g. 4 KiB, which is a convenient size for your OS to do its whole memory management with. And then there’s many things the OS does with such pages.

              Page caching keeps files that processes loaded from your hard drive in RAM, after the process doesn’t need it anymore.

              What you’re referring to is kind of the opposite. The OS allows processes to reserve more memory than there is physically available. This is called “virtual memory”.
              When processes do that, then some of those portions of memory pages get put onto your hard drive, and only get put back into RAM (replacing something else) when the process actually accesses those pages.

              • ruse8145@lemmy.sdf.org
                1·
                3 months ago

                The fundamental result isn’t much different, there’s 30 GB of populated memory being sent to disk because these apps all over allocate and the os insists on sending it to disk even with 40% of real ram free.

          • Ephera@lemmy.ml
            1·
            3 months ago

            What they’re saying is that because of this caching, unused RAM is essentially just not a thing. Any process using lots of RAM will slow down everything else on your PC.

  • zweieuro@lemmy.world
    1·
    3 months ago

    This is expected behaviour though?

    Realisticly, it would be beyond wrong to have every file in ram at all times, or process’s every file to any extend when it is not in immediate use or you are in a search field or link/back link Dialog.

    Try copy pasting 2GB of data into your vim and you will find it takes quite a while for everything to be pasted. When you drag and drop via the UI in obsidian and you do that with thousands of files, then this is not very surprising to slow your application. Assuming obsidian wants to make the files available as soon as possible, I presume it parses/indexes them immediately one after the other instead of one big block.

    My vault is about 1.5k files, all interlinked in some way (ignoring larger pictures or PDFs). Making a new vault and drag and dropping all of them in lags quite a bit for quite a while, but once everything is loaded its fine.

    • graphito@sopuli.xyzOP
      1·
      3 months ago

      Unfortunately, it’s pretty much pointless to point out real widespread problems to the official communities.

      It’s populated by crowd of paid shills and dog pilers who will gladly blame user for any problem, refuse to admit the problem exist, contradict your words and just straight up lie using marketing double speak & sophistry

      You can’t make person to see, when she’s paid not to see