On Tue 10 May 2016 17:02, Andy Wingo <wi...@pobox.com> writes: > (with-output-to-file "/tmp/testies.txt" (lambda () (do-times #e1e6 > (write-char #\a))))
Sorry, I meant #e1e7. The file really does have 10M characters. Actually 10M+1 because of a do-times bug :P > > 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. > > Conclusions: > > 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 > pointers. > > 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. > > Andy
