this post was submitted on 28 Oct 2023
71 points (93.8% liked)
Asklemmy
43870 readers
1366 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy π
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- [email protected]: a community for finding communities
~Icon~ ~by~ ~@Double_[email protected]~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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
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
I'm glad to hear that, I had fun, too. Thank you for your time and have an amazing day, kind stranger
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.