Closed rdmark closed 1 month ago
Results from lantest benchmarks (afptest). I'm seeing a bit more volatility in the read/write numbers for 4.0.0. But the median results are pretty much comparable. The server-under-test (Debian Linux) is wired gigabit ethernet, while the afptest client (macOS Sonoma) is connected via WiFi.
RUN 1
Opening, stating and reading 512 bytes from 1000 files 40048 ms Writing one large file 2594 ms for 100 MB (avg. 40 MB/s) Reading one large file 1903 ms for 100 MB (avg. 55 MB/s) Locking/Unlocking 10000 times each 69139 ms Creating dir with 2000 files 16791 ms Enumerate dir with 2000 files 677 ms Create directory tree with 10^3 dirs 4724 ms
RUN 2
Opening, stating and reading 512 bytes from 1000 files 39419 ms Writing one large file 2646 ms for 100 MB (avg. 39 MB/s) Reading one large file 1560 ms for 100 MB (avg. 67 MB/s) Locking/Unlocking 10000 times each 69527 ms Creating dir with 2000 files 16769 ms Enumerate dir with 2000 files 374 ms Create directory tree with 10^3 dirs 4977 ms
RUN 3
Opening, stating and reading 512 bytes from 1000 files 41321 ms Writing one large file 2099 ms for 100 MB (avg. 49 MB/s) Reading one large file 4217 ms for 100 MB (avg. 24 MB/s) Locking/Unlocking 10000 times each 68410 ms Creating dir with 2000 files 16062 ms Enumerate dir with 2000 files 251 ms Create directory tree with 10^3 dirs 4697 ms
RUN 1
Opening, stating and reading 512 bytes from 1000 files 38015 ms Writing one large file 2211 ms for 100 MB (avg. 47 MB/s) Reading one large file 1536 ms for 100 MB (avg. 68 MB/s) Locking/Unlocking 10000 times each 70979 ms Creating dir with 2000 files 24842 ms Enumerate dir with 2000 files 394 ms Create directory tree with 10^3 dirs 4723 ms
RUN 2
Opening, stating and reading 512 bytes from 1000 files 41702 ms Writing one large file 2509 ms for 100 MB (avg. 41 MB/s) Reading one large file 1527 ms for 100 MB (avg. 68 MB/s) Locking/Unlocking 10000 times each 72051 ms Creating dir with 2000 files 16244 ms Enumerate dir with 2000 files 306 ms Create directory tree with 10^3 dirs 4739 ms
RUN 3
Opening, stating and reading 512 bytes from 1000 files 39595 ms Writing one large file 2627 ms for 100 MB (avg. 39 MB/s) Reading one large file 1487 ms for 100 MB (avg. 70 MB/s) Locking/Unlocking 10000 times each 70047 ms Creating dir with 2000 files 16626 ms Enumerate dir with 2000 files 330 ms Create directory tree with 10^3 dirs 4889 ms
I suspect its just Wifi's usually latency spikes. My primary concern was having to add a switch statement back into write_fork()
and read_fork()
for AppleTalk support.
@NJRoadfan You are referring to the below two switch statements, right? One idea for a safeguard would be to put the syntax of the switch statement itself behind the ifndef NO_DDP macro so that when compiled without AppleTalk support, the code path doesn’t have the obj->proto comparison at all. So if there is a performance hit people can bypass it if needed. Thoughts?
This is what I had in mind: https://github.com/Netatalk/netatalk/pull/1534
I'll try to get afptest benchmarks working again to run the lantest (erroring out right now for some reason.)
My concern was performance with AppleTalk enabled as there is now a branch check during every fork read/write. I don't think there will be any performance hit if AppleTalk is disabled, but I'm assuming the C compiler is smart enough to optimize out a switch statement with one option!
Well, I guess the evidence of any major performance drop is not in the numbers. Let's revisit this if we get reports from the field that something has gone terribly wrong.
Retroactively, I have validated that the AFP specification test is passing, and all discrepancies from 3.x to 4.0 addressed.
Additionally, the spectest is now running in GitHub CI. A recent test report from the v4.0.5 release version:
===================
TEST RESULT SUMMARY
-------------------
Passed: 274
Failed: 0
Skipped: 23
Not tested: 0
https://github.com/Netatalk/netatalk/actions/runs/11760272015/job/32760640992
This is to run the afptest suite against 4.0.0 release candidate code.