[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deffering redisplay in COMINT
From: |
Stefan Monnier |
Subject: |
Re: Deffering redisplay in COMINT |
Date: |
Fri, 11 Jan 2013 10:55:49 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
> but that's what I have to live with). Without the filter and
> auto-hscroll-mode engaged, the results take nearly 30 seconds to
> complete under Emacs. (It is nearly instantaneous outside of Emacs.)
> With the filter you suggest, the results take about 8-10 seconds with
> a noticeable stutter between each row. With the solution I had
> developed (buffering the long lines in a buffer and restoring them at
> the end of output), the results scroll by quickly in about 2-3 seconds,
> but then it hesitates at the end (as it restores the long lines in the
> buffer), for another 2-3 seconds. So just reducing the horizontal
> scrolling is giving us the big payback and the more complex
> gymnastics is probably not worth code cost.
Hmm... I'm wondering why the "one line at a time" approach ends up
slightly slower than your more complex approach. Using a single string
occurs an O(N^2) overhead (where N is the line length: we receive O(N)
packets per line and for each package we do a concat which costs O(N)),
so that might be the reason (which is why I suggested using a list of
strings, tho it makes detection of the prompt more cumbersome), but for
8KB lines it's not clear it would be that bad.
Could you M-x profiler-start ... M-x profiler-report around your tests
to see where the time is spent?
Stefan