Here's a CHDK-less SD benchmark.
Thanks. I finally had the chance trying it.
Here is a typical run (from CBasic), using a Sony branded 16GB (UHS-I, U1, "94MB/s") card that looks similar to this:
loaded A/CBBENCH.BIN size 132 at 0x005325c0
time 2770 speed 46 MB/s
time 2940 speed 43 MB/s
time 2940 speed 43 MB/s
time 2940 speed 43 MB/s
time 2930 speed 43 MB/s
time 2940 speed 43 MB/s
time 2940 speed 43 MB/s
time 2940 speed 43 MB/s
min 2770 max 2940 avg 2917 avg speed 43 MB/sIt looks like 43MB/s is the maximum writing speed that can be expected (cam was the M10, same results with/without CHDK + card reset hack). Apparently, "we" did not get the same card speed as the 80D.
I'm not surprised, we have seen cameras with the "same" digic give different performance before. The same CPU can be tied to peripherals with faster or wider buses etc. The RAM difference Ant pointed out would only apply the difference were in a very limited number of RAM buffered shots.
It would be interesting to see what results you get on sx280.
It might also be interesting to benchmark the card in a PC with a fast UHS reader.
The CHDK benchmark module's results are much worse and fluctuating.
It would be nice to figure out why this happens.
Once difference is that cbbench does one open, 16 writes and then a close, while the CHDK benchmark does an open / close cycle for each write. The open/closes aren't included in the benchmark time in either case, but might affect overhead in other ways.
If the camera were buffering a significant amount of data until close, this could give cause inaccurate results, but IMO 128 MB is much more than the firmware buffers at this level, and the results bear it out: If a substantial portion was being buffered, slow cards would appear as fast as fast cards.
When I did the parallel DNG code, we noticed close can take a noticeable amount of time (~tens of ms) but this is small in comparison to multi-megabyte write times.
Another difference is that cbbench uses a fixed 8 MB write size (which IIRC one of the common block sizes SD cards use) while CHDK bench a fraction of the raw buffer size, which likely does not match any of the underlying block sizes.
CHDK tries to use the raw buffer, but in playback mode that address space may be used for something else. cbbench uses the start of uncached address space, which may be suspect given that the some of the corresponding cached address space is likely occupied by TCM. It might make more sense to start with uncached + 1 MB or something like that.