On Sun, May 31, 2015 at 10:57 AM, Colomban Wendling < lists.ban@herbesfolles.org> wrote:
Le 31/05/2015 07:41, Lex Trotman a écrit :
On 31 May 2015 at 11:46, Lex Trotman elextr@gmail.com wrote:
On 31 May 2015 at 08:05, Thomas Martitz kugel@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, […]
So its almost certainly slower than strstr().
And on my system strstr() is a builtin that can use any hardware support available.
One thing that will make strstr() sound a lot less sexy is that you probably actually want to find *words* rather than substrings. Meaning that if the word under the cursor is "i", you probably don't want to highlight all "i"s in e.g. an identifier "highlighting", but only whole words. And while Scintilla search has the logic for this (SCFIND_WHOLEWORD), it'd probably be annoying/redundant to re-do with the same logic.
Apart that, yes, strstr() from an optimized libc like glibc will be hard to beat without also using very smart optimization combined with use of specialized CPU instruction sets.
Cheers, Colomban
Just to clarify, when I mentioned strstr(), I meant it as an example of using some existing implementation (instead of creating something new) rather than suggesting strstr() is the "best" one. If there's something in Scintilla which would make it easier to implement this feature, just go for it. If there's some performance problem, it can always be improved afterwards (but I don't think there will be any).
Regards,
Jiri