#271 SCI_SEARCHINTARGET is so slow...

[Cha Sangcheol]

I wrote some codes that search
(SCI_SEARCHINTARGET) a string with Scintilla 1.62

It takes too long time to search the string.

I checked time to search the string and I used the same
code(written by me) but different Scintilla dll file.

It took 3.095sec with Scintilla 1.62 and took 0.442sec
with Scintilla 1.57.

Although Scintilla 1.57 is faster than Scintilla 1.62, it is
also somewhat slow...

Following code is written by me. Is there any problems?

----------------------------------------------------------------------------------
-----
int nStart, nEnd;
GetSelection(nStart, nEnd);

nStart = 0;
nEnd = GetDocLength\(\);

int findPos = 1;    
SetTargetEnd\(nEnd\);
int nFlags = 0;
nFlags |= \(flags &

CE_FIND_WHOLEWORD) ? SCFIND_WHOLEWORD :
0;
nFlags |= (flags &
CE_FIND_MATCHCASE) ? SCFIND_MATCHCASE : 0;
SendEditor(SCI_SETSEARCHFLAGS,
nFlags);

int replaceCnt = 0;
BeginUndoAction\(\);

CNanoTime timer;
timer.Start();
while (findPos != -1)
{
SetTargetStart(nStart);
SetTargetEnd(GetDocLength());

    findPos = SearchInTarget

((LPTSTR)(LPCTSTR)strToFind, strToFind.GetLength());

    if\(findPos \!= -1\)
    \{
        nStart = GetTargetStart

();
ReplaceInTarget
(GetTargetStart(), GetTargetEnd(), (LPTSTR)(LPCTSTR)
strToReplace);
}
else
break;
}
TRACE("%f\n", timer.GetMilli());
----------------------------------------------------------------------------------
-----

[Neil Hodgson]

Logged In: YES
user_id=12579

This line is suspicious:
ReplaceInTarget(GetTargetStart(), GetTargetEnd(),
(LPTSTR)(LPCTSTR)strToReplace);
You haven't shown the definition of ReplaceInTarget but the
normal wrapping of the API would be
ReplaceTarget(GetTargetEnd() - GetTargetStart(),
(LPTSTR)(LPCTSTR)strToReplace);

The most common reason for poor performance of find and
replace is use of DBCS as this requires calls to WIndows to
determine where characters end.

[Nobody/Anonymous]

Logged In: NO

Thanks for answering my question...
But I didn't understand what you said. I'm a beginner...-_-;
You said "using of DBCS" makes performace of find and
replace. Then should I convert text to unicode and pass a
search function(SCI_SEARCHINTARGET call)? Or should I
convert a file to unicode when I open a file to edit?
Which is right?

[Neil Hodgson]

Logged In: YES
user_id=12579

First see if this is the problem by experimenting in SciTE.
Try the example document and search string with
character.set and code.page set to whatever you want to use
in your editor. Then try the same thing with SciTE in
unicode: Edit | Select All, Edit | Copy, open a new copy of
SciTE, File | Encoding | UTF-8, Pasten and then perform the
search. If the initial time is similar to your experiment
and the unicode time is much faster then it may be sensible
to use unicode as the encoding in your application. You may
need to convert to and from UTF-8 when loading/saving the
document and when performing searches. SCI_SEARCHINTARGET
knowd how to work in UTF-8 but you need to ensure that the
search string has been converted to UTF-8.

[Cha Sangcheol]

Logged In: YES
user_id=908104

Thanks In my application, I set the codepage as 949. I
disabled the DBCS support and tried search. Then searching
was so fast
Again, I appreciate your help

[Neil Hodgson]

Logged In: YES
user_id=12579

It may be possible to enhance Scintilla to cache the results
of IsDBCSLeadByteEx for a particular code page and avoid
many operating system calls, thus speeding up this function.
However, many people are happy with using unicode so it
hasn't been done. It is more difficult to speed up more
complex encodings such as EUC-JP.