[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-zile] Zi is slow :( [WAS Re: Rebasing Zi]
From: |
Gary V. Vaughan |
Subject: |
[Bug-zile] Zi is slow :( [WAS Re: Rebasing Zi] |
Date: |
Thu, 23 Feb 2012 06:42:23 +0700 |
Rebased and push zi and topic/syntax-hilite again.
On 21 Feb 2012, at 20:40, Gary V. Vaughan wrote:
> On 15 Feb 2012, at 16:18, Gary V. Vaughan wrote:
>> So the new Zi branch is much cleaner and shorter, and picks up all
>> the fixes and improvements from the Lua branch without adding another
>> merge commit :)
>
> Only, it was *so* short that a couple of the mega-patches proved annoyingly
> difficult to rebase again over the last week of work on the Lua branch,
> so I've split them up into more pieces with the most recent rebase, in the
> hope this makes the next rebase easier to do - instead of getting all the
> conflicts at once! :)
>
> While I was there, I also pushed my syntax-hilite branch (such as it is
> so far) in case any one wants to point me in a different direction before
> I get too far along this route.
Rebasing is much easier now that I can resolve a conflict here and there,
run the testsuite and rebase --continue. Phew!
Anyway, totally out of hacking time this month, so I'll be quiet for a
week or two now.
Apart from an implementation of multi-line syntax expression matching, and
nesting of grammars, the syntax-highlighting is working rather better than I
had expected. So, keywords and constants and a few others are colored
according to the theme, and update correctly as you type!
Sadly, it is still on the edge of annoyingly slow, I trust we'll be able
to fix that later with libffi and/or profiling for the hotspots. Zi was
already slow before syntax highlighting, but only so much that I would notice
it when pasting, or typing at full speed for a while and having to pause for
the cursor to catch up :)
Now, even cursor movements are noticeably laggy :( A quick look at the code
makes me think that the buffer-gap is being dragged around behind the cursor
on each movement. If I'm reading the code right, some low-hanging fruit for
optimisation would be to only move the buffer-gap if a self-inserting key is
pressed. WDYT?
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)