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

[Gary V. Vaughan]

Hi Reuben,

On Jan 18, 2014, at 6:26 PM, Gary V. Vaughan <address@hidden> wrote:
> On Jan 18, 2014, at 4:03 PM, Gary V. Vaughan <address@hidden> wrote:
>> [[...]] 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.
> 
> This speeds things up drastically for me - though most likely still an order 
> of magnitude slower than memrchr in libc:
> 
>  local function memrchr (buf, ch, o)
>    local c = string.byte (ch)
>    for i = o, 1, -1 do
>      if buf[i] == c then return i end
>    end
>  end
> 
> I'll push that change presently as it's a definite improvement.

And it works on my Mac and at Travis:

https://travis-ci.org/gvvaughan/zile/builds/17213299 @890677b

So I tried to add a memrchr wrapper for gnulib machines like this:

https://github.com/gvvaughan/zile/commit/9de1fe27032862effe99134db66bef76b11d147b

local have_memrchr, memrchr = pcall (loadstring [[
  alien.default.memrchr:types ("pointer", "pointer", "int", "size_t")

  return function (buf, ch, o)
    local b = buf.buffer
    local prev = alien.default.memrchr (
      b:topointer (o), string.byte (ch), o - 1)
    return prev and b:tooffset (prev) or nil
  end
]])

if not have_memrchr then
  -- Brute force reverse buffer search using alien.array [] references.
  function memrchr (buf, ch, o)
    local c = string.byte (ch)
    for i = o, 1, -1 do
      if buf[i] == c then return i end
    end
  end
end

Which continues to work on my Mac (because it fails the have_memrchr check and 
uses the
fallback implementation), but blows up spectacularly on Travis:

https://travis-ci.org/gvvaughan/zile/builds/17213305 @9de1fe2 

If you had time to try out those two revision on your Linux machine, and help 
me figure out how
I screwed up the alien memrchr wrapper in the latter, that would be awesome!

After we fix that, I'll start to pull in the tostring() removals and other 
speedups that lead
to the is each slowness you originally reported.

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

signature.asc
Description: Message signed with OpenPGP using GPGMail