On Jan 22, 2018, at 6:44 AM, Martin Vahi <[email protected]> wrote: > > Fossil had an opportunity to allocate > at least 1GiB of RAM
There are cases where Fossil needs 2-3x the size of an object to operate. For example, my understanding of the way Fossil does the diff operation is that it loads the new and old files into memory, and then it creates an output buffer which needs to be large enough to hold the differences. You speak of algorithms, and indeed, you might talk about creating a sliding window version of the diff algorithm so that you only need something like 1.2N memory, where N is the size of the output buffer, the rest going to the input files’ sliding windows, but then we get back to the need for motivating examples. With 1 GB of RAM and presumably some nonzero multiple of that for VM, the current Fossil diff algorithm only breaks down when you’re checking in diffs on files hundreds of megs in size, which begs the question, “Seriously?” > In my opinion the correct > case might be that Fossil should be able to run even > on the old Raspberry Pi 1 that has 512MiB RAM It does. One of my public Fossil projects is based on the Pi, and the Pi B+ remains a major development and deployment target. It’s not surprising that it works well there, since the largest file in this project’s Fossil repository is 3.3 MB and the total repository size is 37 MB, so 512 MB of RAM and some amount of VM on top of that is plenty for this particular application. I got all of that from my repository’s /stat page. What does your repository’s /stat page show? > Fossil should just look, > how much free RAM the computer has Easier said than done, which is why the C Standard doesn’t have a way to get that number. No single one of the answers to this similar question on Stack Overflow are entirely correct: https://stackoverflow.com/questions/2513505/how-to-get-available-memory-c-g When it takes multiple answers which are correct within a fixed scope to come up with a proper cross-platform solution, it’s a good bet that you’re probably chasing the wrong problem. (The accepted answer to that question is arguably even wrong. It’s certainly unsuitable for Fossil’s purposes.) Even if Fossil were to mash up all of that advice into a solution that works everywhere, Windows, Linux, and the BSDs (including macOS, in this case) don’t all agree on what “free RAM” means. The BSDs have the concept of “wired” memory, which doesn’t exist on the other two. Windows has non-pageable RAM, which the other two don’t, etc. Then you add in all the other random OSes Fossil runs on, and things get even more complicated. > adjust its algorithm parameters accordingly. Fossil makes some reasonable assumptions about its working environment: individual file sizes are a small fraction of available VM, the entire repository probably fits into VM, and if not, then it can at least get several artifacts into VM at once, etc. If you’re dealing with artifact sizes a large fraction of the size of your virtual memory size, then you’re probably asking for trouble with Fossil. Fossil would have been designed differently if that were the common use case. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
