Menu
▾
▴
#1158 maybe a performance bug？
when wrap is enabled, and if a big file (for example size>5MB) with many long lines is opened, then, if switch to another opened tab and switch back again, it will need many seconds to show the content again, while gedit is quick. And if there is no wrap, it is as quick as gedit. Is there any solution?
Scite version is 2.25 on linux x86_64
Use a separate instance of SciTE for large files.
this is a solution, but I think there maybe some unnecessory operation when switching to a new tab?
SciTE works by having a single edit widget in the edit pane with multiple document objects. When a tab is selected, the document object attached to the edit widget is swapped. All the visual state for this document is lost and must be recreated. Other editors use multiple edit widgets, each owning a document so less is changed when switching tabs but more memory is used. Changing this in SciTE would be a large amount of work.
There may be some other operations that could be avoided when switching tabs. If motivated, you could run under a profiler and see what is taking the time for your file.
profile of switching to an opened file using oprofile (wrap is enabled)
CPU: Core 2, speed 2341.05 MHz (estimated)
Counted INST_RETIRED_ANY_P events (number of instructions retired) with a unit mask of 0x00 (No unit mask) count 100000
samples % symbol name
9571 19.8231 Editor::LayoutLine(int, Surface*, ViewStyle&, LineLayout*, int)
4324 8.9557 SplitVector<int>::ValueAt(int) const
2884 5.9732 SplitVector<char>::ValueAt(int) const
2671 5.5321 Document::IsDBCSLeadByte(char) const
2549 5.2794 SurfaceImpl::MeasureWidths(Font&, char const*, int, int*)
2548 5.2773 MultiByteLenFromIconv(Converter const&, char const*, unsigned long)
1958 4.0553 Converter::Convert(char**, unsigned long*, char**, unsigned long*) const
1935 4.0077 Document::MovePositionOutsideChar(int, int, bool)
1699 3.5189 Partitioning::PartitionFromPosition(int) const
1596 3.3056 SplitVector<int>::Length() const
1551 3.2124 Converter::Succeeded() const
1394 2.8872 Partitioning::PositionFromPartition(int) const
1392 2.8831 IsControlCharacter(int)
1220 2.5268 IsSpaceOrTab(int)
1205 2.4958 unsigned long iconv_adaptor<char**>(unsigned long (*)(_GIConv*, char**, unsigned long*, char**, unsigned long*), _GIConv*, char**, unsigned long*, char**, unsigned long*)
1136 2.3528 Editor::IsUnicodeMode() const
1068 2.2120 UTF8CharLength(char const*)
that sound reasonable. The memory is enough today, and one document object with one edit widget would be a better choice.
and when wrap is off, SciTE works as good as other editor
when I comment the following two lines:
wEditor.Call(SCI_ENSUREVISIBLEENFORCEPOLICY, lineStart);
wEditor.Call(SCI_ENSUREVISIBLEENFORCEPOLICY, lineEnd);
in function:
void SciTEBase::DisplayAround(const RecentFile &rf) {}
it works well and performance is good, the behavior of SciTE is as same as before, is that OK?
Is this a SciTE problem or a Scintilla problem? If SciTE rather than Scintilla, maybe it is not a problem in some other Scintilla based editors (like Geany, Notepad++, or similar)?
The lines quoted are responsible for making sure the selection is seen when switching back to a tab.
Looking at your profile shows calls like IsDBCSLeadByte which should only be used for documents in an Asian DBCS encoding. Since GTK+ is based on Unicode, there is a performance cost in translating to UTF-8 and you may find SciTE more responsive if you translate your file to UTF-8.
this isa SciTE problem , the reason is as nyamatongwe said: there is only one edit widgets in SciTE, while other editors have multiple. Geany performs well.
when I commented the two lines, the selection can be seen when switching back to a tab just like before.
the file encoding is GBK, and there will be translating cost. when I convert the file to UTF-8 encoding, switching is also slow.
Counted INST_RETIRED_ANY_P events (number of instructions retired) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name symbol name
17797 39.2229 SciTE Editor::LayoutLine(int, Surface*, ViewStyle&, LineLayout*, int)
3658 8.0619 SciTE BadUTF(char const*, int, int&)
3480 7.6696 SciTE SplitVector<int>::ValueAt(int) const
2870 6.3252 SciTE SurfaceImpl::MeasureWidths(Font&, char const*, int, int*)
1906 4.2006 SciTE IsSpaceOrTab(int)
1746 3.8480 SciTE Partitioning::PartitionFromPosition(int) const
1616 3.5615 SciTE Partitioning::PositionFromPartition(int) const
1353 2.9819 SciTE SplitVector<int>::Length() const
1336 2.9444 SciTE Editor::IsUnicodeMode() const
1038 2.2877 SciTE IsControlCharacter(int)
1015 2.2370 SciTE ClusterIterator::Next()
810 1.7852 SciTE GoodTrailByte(int)
The code in that area has changed over time with the SCI_ENSUREVISIBLEENFORCEPOLICY initially needed to ensure the ends of the selection were unfolded and so visible. It looks like this is now achieved by the code that remembers the folding state. I haven't been able to provoke any bad behaviour without those lines but there may be cases I haven't thought of. I'll take them out but they may need to return if there are reported problems.