Re: [Bug-zile] Incremental search is dog slow in moderately-sized files

[Gary V. Vaughan]

Hi Reuben,

On Jan 18, 2014, at 9:33 AM, Reuben Thomas <address@hidden> wrote:

> Zee, having cleaned the bitrot, works fast. (luarocks install 
> zee-git-1.rockspec should work now.) I suspect this is a clue:
> 
> commit 1c308523155b1c8f344223f2591a0ad7d5834bec
> Author: Reuben Thomas <address@hidden>
> Date:   Wed Oct 3 02:13:44 2012 +0100
> 
>     search.lua: simplify find_substr to allow only searching from point
>     
>     As a result, remove the last calls to tostring for the entire buffer
>     contents, and make searching the buffer much more efficient.
>     
>     Also remove the non-regex search option, which is no longer used.
> 
> I can't find a corresponding commit in Zile.

Thanks for the clue.

Looking back through the commits that one depends on ends up back at the 
alien.memrchr call, which Mac OS X doesn't have, so I haven't pulled that or 
any of the other stuff it depends on into Zile since it would stop me from 
running it here entirely.  I remember stalling on this a year or two back, but 
I was never able to come up with a satisfactory equivalent or alternative -- 
but that at least explains why zmacs slows to a crawl with any moderate sized 
files in its current state, where zee is using the *much* faster memrchr, which 
trickles through to a ton of other optimizations.

My first stab at a oniguruma based syntax highlighter started to come unstuck 
here too, since zile still needs lrex-gnu for many primitive buffer operations, 
such as `previous-line`, so I really *would* like to figure out an elegant 
portable solution., but the only thing I can think of is to add bi-directional 
char buffer searches into alien itself, with a fallback memrchr function incase 
the host libc lacks one.

Thoughts?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

signature.asc
Description: Message signed with OpenPGP using GPGMail