bug-zile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary V. Vaughan
Subject: Re: [Bug-zile] Incremental search is dog slow in moderately-sized files
Date: Sun, 19 Jan 2014 23:11:41 +1300

On Jan 19, 2014, at 10:16 PM, Gary V. Vaughan <address@hidden> wrote:
> 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.


Incidentally, I tried porting my memrchr into zee to see if I could get that 
going on Mac but
still no luck there:

  1. @LUA@ is not substituted in .../bin/zee
  2. luarocks.loader fails to find module zee
  3. After trying again in a brand new rocks tree with just the zee 
dependencies,
     `lua52 .luarocks/bin/zee` returns to the prompt immediately with no 
indication
     of why it bailed out.

It still might be a better way for you to help me figure out where my memrchr 
wrapper is borked,
than roaming around among all the changes I've made to Zile since you last 
worked on it :)

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


reply via email to

[Prev in Thread] Current Thread [Next in Thread]