[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wip-ports-refactor
From: |
Ludovic Courtès |
Subject: |
Re: wip-ports-refactor |
Date: |
Sun, 17 Apr 2016 12:44:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Andy Wingo <address@hidden> skribis:
> I want to test four things.
>
> ;; 1. How long a loop up to 10 million takes (baseline measurement).
> (let ((port (open-input-string "s"))) (do-times #e1e7 1))
>
> ;; 2. A call to a simple Scheme function.
> (define (foo port) 42)
> (let ((port (open-input-string "s"))) (do-times #e1e7 (foo port)))
>
> ;; 3. A call to a port subr.
> (let ((port (open-input-string "s"))) (do-times #e1e7 (port-line port)))
>
> ;; 4. A call to a port subr that touches the buffer.
> (let ((port (open-input-string "s"))) (do-times #e1e7 (peek-char port)))
>
> The results:
>
> | 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
Oh, nice! (By “prohibitively slow” I was referring to 2.0.)
For ‘peek-char’, isn’t there also the fact that string ports in 2.2 are
UTF-8 by default, so we get the fast path, whereas in 2.0 there
‘%default-port-encoding’, which could be something else leading to the
slow path?
Would be nice to check if doing:
(with-fluids ((%default-port-encoding "UTF-8"))
(open-input-string "s"))
makes a difference in the 2.0 measurements.
I hadn’t realized that subr calls had become this cheaper in 2.2, that’s
awesome.
> Anyway. I think that given the huge performance window opened up to us
> by the 2.0->2.2 switch, we should consider speed considerations as
> important but not primary -- when given a choice between speed and
> maintainability, or speed and the ability to suspend a port, we
> shouldn't choose speed.
Agreed.
> That said, the real way to make port operations fast is (1) to buffer
> the port, and (2) to operate on the buffer directly instead of fetching
> data octet-by-octet. Exposing the port buffer to Scheme allows this
> kind of punch-through optimization to be implemented where needed.
In fact my comment about speed was because I was expecting the
port-refactor work to improve performance for things like ‘read-char’,
which seems to be the case already.
Thank you!
Ludo’.
Re: wip-ports-refactor, Chris Vine, 2016/04/24