armv7 cpu usage

I am profiling on armv7 and seems that the password protected web interface and stat syscall are two or the most expensive calls

 638  25.3%  25.3%      638  25.3%
 275  10.9%  36.2%      275  10.9% bytes.Compare
 225   8.9%  45.1%      234   9.3% syscall.Syscall
 109   4.3%  49.4%      185   7.3% runtime.mallocgc
(pprof) top10
Total: 1510 samples
     324  21.5%  21.5%      336  22.3% syscall.Syscall
     141   9.3%  30.8%      141   9.3% hash/crc32.update
     119   7.9%  38.7%      119   7.9% runtime.memmove
     113   7.5%  46.2%      113   7.5% syscall.Syscall6
     105   7.0%  53.1%      183  12.1%
      77   5.1%  58.2%       77   5.1% bytes.Compare
      56   3.7%  61.9%      117   7.7% runtime.mallocgc

You seem to have profiled syncthing while it’s scanning for changes. That’s basically just walking the tree and stat:ing everything, so yeah. Not sure why the HTTPS connection features so prominently; maybe GUI was loading a bunch of data?

For a 400GB repo with 70K files, rsync can chew through it in a few minutes, and I left syncthing for a 4 or 5 days running and couldn’t manage to pass the initial scan. I was trying to find what’s the reason for this as I was suspecting the sha256 function which is not native if I was looking at the right golang sources. The profile says otherwise, so I’m not exactly sure what is the main bottleneck when running in this underpowered CPU.

You have a 400 GB repo on your phone…?

Anyway, no, that sounds weird. Profile above doesn’t show any hashing, just lots of stat:s and some HTTPS, but it’s also from a limited time window. Once up and running (after initial hashing), it shouldn’t take many seconds or minutes to stat those files.

“STTRACE=scanner” will show you if the hasher is doing any work, or in the GUI just observing the state “scanning” and the number of files seen in the repo increasing. There’s a fair amount of GC going on in that profile above as well; normally this is a non-issue but if you are constrained on the CPU cycles it can help to give it a little more memory to play with; try setting the environment variable “GOGC=100” (allows heap to grow to 100% over active utilization, opposed to the syncthing default of 25%).