[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Christopher Allan Webber
Wed, 11 May 2016 09:00:47 -0500
mu4e 0.9.13; emacs 24.5.1
Andy Wingo writes:
> On Sun 17 Apr 2016 10:49, Andy Wingo <address@hidden> writes:
>> | baseline | foo | port-line | peek-char
>> guile 2.0 | 0.269s | 0.845s | 1.067s | 1.280s
>> guile master | 0.058s | 0.224s | 0.225s | 0.433s
>> wip-port-refactor | 0.058s | 0.220s | 0.226s | 0.375s
> So, I have completed the move to port buffers that are exposed to
> Scheme. I also ported the machinery needed to read characters and bytes
> to Scheme, while keeping the C code around. The results are a bit
> frustrating. Here I'm going to use a file that contains only latin1
> (with-output-to-file "/tmp/testies.txt" (lambda () (do-times #e1e6
> (write-char #\a))))
> This is in a UTF-8 locale. OK. So we have 10M "a" characters. I now
> want to test these things:
> 1. peek-char, 1e7 times.
> 2. read-char, 1e7 times.
> 3. lookahead-u8, 1e7 times. (Call it peek-byte.)
> 4. get-u8, 1e7 times. (Call it read-byte.)
> | peek-char | read-char | peek-byte | read-byte
> 2.0 | 0.811s | 0.711s | 0.619s | 0.623s
> master | 0.410s | 0.331s | 0.428s | 0.411s
> port-refactor C | 0.333s | 0.358s | 0.265s | 0.245s
> port-refactor Scheme | 1.041s | 1.820s | 0.682s | 0.727s
> Again, measurements on my i7-5600U, best of three, --no-debug.
> 1. In Guile master and 2.0, reading is faster than peeking, because it
> does a read then a putback. In wip-port-refactor, the reverse is
> true: peeking fills the buffer, and reading advances the buffer
> 2. Scheme appears to be about 3-4 times slower than C in
> port-refactor. It's slower than 2.0, unfortunately. I am certain
> that we will get the difference back when we get native compilation
> but I don't know when that would be.
> 3. There are some compiler improvements that could help Scheme
> performance too. For example the bit that updates the port
> positions is not optimal. We could expose it from C of course.
> Note that this Scheme implementation passes ports.test, so there
> shouldn't be any hidden surprises.
> I am not sure what to do, to be honest. I think I would switch to
> Scheme if it let me throw away the C code, but I don't see the path
> forward on that right now due to bootstrap reasons. I think if I could
> golf `read-char' down to 1.100s or so it would become more palatable.
Happily at least, none of these benchmarks are *that much* slower than
Guile 2.0. So most "present day" users won't be noticing a slowdown in
IO if this slipped into the next release.
You're probably right (is my vague and uninformed suspicion) that native
compilation would speed it up.
My thoughts are: if this refactor could bring us closer to more useful
code for everyday users, a small slowdown over 2.0 is not so bad. Eg,
if we could get SSL support, and buffered reads with prompts,
etc... those are good features. So if you had my vote I'd say: forge
ahead on adding those, and if they come out well, then I think this
merge is worth it anyway, despite a small slowdown in IO over 2.0.
Hopefully we'll get it back in the future anyway!