[Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
elextr at xxxxx
Sun May 31 05:41:07 UTC 2015
On 31 May 2015 at 11:46, Lex Trotman <elextr at gmail.com> wrote:
> On 31 May 2015 at 08:05, Thomas Martitz <kugel at rockbox.org> wrote:
>> Am 30.05.2015 um 03:19 schrieb Matthew Brush:
>>> Just because it's such a trivial search algorithm, using strstr() is much
>>> more simple and probably more efficient than using Scintilla's API to find
>>> text, but if manual and automatic mode is supported, it would make sense to
>>> share the existing code, and that beats out advantage having a redundant
>>> (yet simpler/faster) routine to do same, IMO. +1 (if it's not too much
>>> hassle to refactor "Mark All").
>> What makes you think naive strstr() based search is faster/more efficient
>> than whatever Scintilla does?
>> I haven't looked actually, but I'd think it does the same (probably using
>> C++ strings), or something smarter like KMP mentioned in this thread or
>> whatever the C++ template library provides. But I don't think it does
>> anything slower than the most trivial strstr() method.
> Scintilla uses its own home rolled gap buffer, not C++ strings (for
> the text and styles). For plain case sensitive "find text" it uses
> the naive algorithm, but each char from the buffer is accessed by
> Document::charat() which will probably inline as its in the header
> and its only a call to CellBuffer::charat() which probably won't
> inline since its in the cxx file not the header and which calls
> SplitVector::charat() which is in the header and may or may not inline
> due to its size (15 lines).
> So its almost certainly slower than strstr().
And on my system strstr() is a builtin that can use any hardware
> But to be able to use strstr() (or any other algorithm that needs
> contiguous text) the gap needs to be closed, so a large block of text
> and styles need copying, which is done by memmove() which I think uses
> intrinsics if available so it probably runs at memory speed so its
> fast. But its something else that complicates comparing speeds :)
> Essentially the only way to tell is to try benchmarks for a
> (hopefully) representative set of cases.
>> Best regards.
>> Devel mailing list
>> Devel at lists.geany.org
More information about the Devel