First of all, I want to say that I am not sure whether this is a generic problem, or rather something limited to my Android devices only. Anyhow, on two different multi-core devices, I have observed that Syncthing seems to treat them as single-core. With the default MaxFolderConcurrency (i.e. “0”), only one folder is being scanned at a time, even though the devices have a dual-core and a quad-core CPUs.
The first CPU is Exynos 4210 Dual (Dual-core 1.2 GHz Cortex-A9). The second CPU is Exynos 4412 Quad (Quad-core 1.6 GHz Cortex-A9). Both seem to be treated as single-core by Syncthing, which means that both MaxFolderConcurrency, hashers, etc. are set to 1, and need to be adjusted manually for optimal performance.
If you open settings, then the preview for the usage reporting data, then select a version, then scroll down until you see numCPU - what does it report there?
Looking at the Go sources, I think that value is straight from what the OS reports using some system call… though the OS can limit the number of CPUs available to the app of course.
I would like to add one observation related to this problem. When using the Android wrapper, it seems to reset settings like hashers to the default values on each start. In this case, this is a big problem, as I am unable to manually modify these settings, ending with hashers = 1 on a quad-core device.
Is this a bug, by design, or perhaps simply an oversight?
In ST Fork, it is enforced to “1” due to issue https://github.com/syncthing/syncthing-android/issues/384 . Maybe as phones get faster and more rock solid android versions over time this decision will proove useless in the future - what I’ve heard around tells me “phones should be able to phone at every possible time” so the user is happy for its functionality even during a Syncthing scan in the background. Those reports like “my phone suddenly reboots under load, apps that I rely on are terminated, cell connection drops on heavy load” personally scared me and took me to this decision. Maybe we’ll make it configurable for you some day :-).
I can understand the logic, but in the case of older devices with multi-core CPUs, yet very weak single-core performance, this really hurts when it comes to scanning performance and time. I would personally much prefer it being limited e.g. to half of the available cores, instead of using all of them, as in the “normal” Syncthing.
Hmm honestly I need to update myself reading the docs about the new maxConcurrency option, maybe that’s just the better solution I waited for since I know Syncthing. Originally, I limited hashers on spinning disks to limit heavy IO slowing the system down, but one hasher per folder isn’t a good approach. It just helps in older ST versions if you also have two or three folders (therefore assumed to be the average mobile sync user)
What strikes my thoughts even more: scanning might be a one time need for most users because then they have little deltas making discussion of scan performance less important. Would be cool if a folder is first scanned or syncthing had discovered how much files need scanning and that’s quite much the ui would offer a gui toggle “hey, you’re scanning a lot atm - we are scanning at medium priority. Would you like to lower or increase that?”
You have a point here, as for me too, it is usually the first scanning that takes forever with hashes set to 1. I am not a regular user though, as I have been doing a lot of testing with different versions of Syncthing and Android, which means starting from scratch all the time, and I also sync my Joplin notes (10000 files) and DecSync calendars (35000 files), which means a huge number of tiny little files to scan.