Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gaertner schrieb: At the moment the fpdoc editor is updated on idle in several steps. Maybe the update should be started after a short delay. Maybe. I'd suggest an thread, but I dunno about platform issues with threads. I also had an crash of lazde, caused by an formatting error in the text. Bugreport submitted. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Zitat von Hans-Peter Diettrich drdiettri...@aol.com: Mattias Gaertner schrieb: At the moment the fpdoc editor is updated on idle in several steps. Maybe the update should be started after a short delay. Maybe. I'd suggest an thread, but I dunno about platform issues with threads. Threads work on all platforms (at least where the IDE runs). The problem is that many tools access the codetools (almost every file access and search). You need critical sections at a lot of places. Or you start a second thread with their own sources/caches. I also had an crash of lazde, caused by an formatting error in the text. Bugreport submitted. Thanks. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gärtner schrieb: The problem is that many tools access the codetools (almost every file access and search). Then a request manager might help, with a busy indication so that a client can skip and retry later. A threaded server will allow for higher throughput on multi-core machines. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
On Tue, Feb 24, 2009 at 05:43:37AM +0100, Hans-Peter Diettrich wrote: I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Now I could spot the trouble source: it's fpdoc! Interesting, I'm just optimizing a part of that. http://bugs.freepascal.org/view.php?id=12953 What exactly is slow in fpdoc? ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
On Tue, 24 Feb 2009 11:36:25 +0100 Marco van de Voort mar...@stack.nl wrote: On Tue, Feb 24, 2009 at 05:43:37AM +0100, Hans-Peter Diettrich wrote: I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Now I could spot the trouble source: it's fpdoc! Interesting, I'm just optimizing a part of that. http://bugs.freepascal.org/view.php?id=12953 What exactly is slow in fpdoc? I guess he meant the fpdoc editor in the IDE, not the fpdoc program. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gaertner schrieb: What exactly is slow in fpdoc? I guess he meant the fpdoc editor in the IDE, not the fpdoc program. Right. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Marco van de Voort schrieb: Now I could spot the trouble source: it's fpdoc! Interesting, I'm just optimizing a part of that. http://bugs.freepascal.org/view.php?id=12953 What exactly is slow in fpdoc? IMO it's the search for documentation information about the current identifier in the edit window, started for almost every move of the caret. If that's the reason for the excessive slowdown of the editor, the search should be performed by a background thread, so that the editor is not blocked. The search should be terminated immediately, when the caret moves to an different identifier. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gaertner schrieb: Now I could spot the trouble source: it's fpdoc! Why do you think so? When the fpdoc window is open, the task manager shows a CPU usage of up to 100%, and every caret move can take several seconds. You can check this behaviour yourself, my test case is the Controls unit with the related include files. When I close the fpdoc window, navigation through the text is not delayed, CPU usage stays at a few percents. Memory usage is constant in either case, swapping seems not to occur. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
On Tue, 24 Feb 2009 16:01:07 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Marco van de Voort schrieb: Now I could spot the trouble source: it's fpdoc! Interesting, I'm just optimizing a part of that. http://bugs.freepascal.org/view.php?id=12953 What exactly is slow in fpdoc? IMO it's the search for documentation information about the current identifier in the edit window, started for almost every move of the caret. If that's the reason for the excessive slowdown of the editor, the search should be performed by a background thread, so that the editor is not blocked. The search should be terminated immediately, when the caret moves to an different identifier. At the moment the fpdoc editor is updated on idle in several steps. Maybe the update should be started after a short delay. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: The effect is boring, even if I only navigate through the source code with the cursor keys :-( This bit sounds like a problem with painting the window. Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. You remember my suggestion, to use an line-cache in the SynEdit component? Such a cache allows to bypass the block folding and other possibly time consuming actions, while only navigating through an file without editing. Which OS / Widgetset are you using? Windows 32 bit. My repaired machine just has arrived, I'll retry under Linux when I've reinstalled the system and Lazarus. You have not mentioned anything, so I just verify, it is nothing that has become worse since 0.9.26 (or within 2009) ? I've not really used Lazarus 0.9.26 or older, now I'm just following the SVN trunk. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: The effect is boring, even if I only navigate through the source code with the cursor keys :-( This bit sounds like a problem with painting the window. Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. yes and no: - vertical moves do repaint the gutter always, in case that the every nth line number is used. - Any caret move that goes across a word boundary triggers the highlight-current-word (but it only set the timer, and only if you wait it does a search in the source), unless you checked disable timer (but this feature has only been added in 2009, hence my question) - If you hit a bracket, there is a quick search for the matching one. and if you are on a begin or end there is a search for the matching word (but if you are not on a begin or similar, this should not affect you). Otherwise: it is true that moving the caret should cost no time. And I can't see where it would relay on anything that could amount over time. I'll keep it in the back of my head, in case I see anything. Maybe I find some time to but some time measuring in. You remember my suggestion, to use an line-cache in the SynEdit component? Such a cache allows to bypass the block folding and other possibly time consuming actions, while only navigating through an file without editing. Still having plans for that. (I also need to start working on a better data-model, for multi view stuff / since you progress on the docking :) ) Yet the current implementation of folding is very quick, and the risk to run out of memory, rather than CPU-time exists too. I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Which OS / Widgetset are you using? Windows 32 bit. Hm, Windows should be the most efficient. GTK has a lot of code to the in grid drawing of the chars. Windows does it natively. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
- Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). that's some kind of an urban legend. But anyway I could cry aloud looking at what mwEdit became. Nobody seems to know anymore how to write efficient code. Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. yes and no: - vertical moves do repaint the gutter always, in case that the every nth line number is used. Okay, but it would be sufficient to repaint only the old and new line's numbers. - Any caret move that goes across a word boundary triggers the highlight-current-word (but it only set the timer, and only if you wait it does a search in the source), unless you checked disable timer (but this feature has only been added in 2009, hence my question) - If you hit a bracket, there is a quick search for the matching one. and if you are on a begin or end there is a search for the matching word (but if you are not on a begin or similar, this should not affect you). I think that I should disable all that eye-candy. I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Maybe, yes. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Waldenburg schrieb: - Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). that's some kind of an urban legend. But anyway I could cry aloud looking at what mwEdit became. Nobody seems to know anymore how to write efficient code. Martin Hi Martin, you're still around? :-) You're right, the LCL became utterly bloated, without a good (discussed and documented) concept. But fortunately it doesn't contain assembler code :-) Efficiency is not normally required in a GUI, the current machines have enough power for themes, transparent windows, and more. But the behaviour of LazSynEdit actually feels a bit like the initial RAD-Studio editor, which also tended to slow down, until a freeze. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. yes and no: - vertical moves do repaint the gutter always, in case that the every nth line number is used. Okay, but it would be sufficient to repaint only the old and new line's numbers. Which is what it does, just 2 line numbers. - Any caret move that goes across a word boundary triggers the highlight-current-word (but it only set the timer, and only if you wait it does a search in the source), unless you checked disable timer (but this feature has only been added in 2009, hence my question) - If you hit a bracket, there is a quick search for the matching one. and if you are on a begin or end there is a search for the matching word (but if you are not on a begin or similar, this should not affect you). I think that I should disable all that eye-candy. Let me know, if any of that makes a diff. I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Maybe, yes. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Waldenburg schrieb: - Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). that's some kind of an urban legend. But anyway I could cry aloud looking at what mwEdit became. Nobody seems to know anymore how to write efficient code. Martin Hi Martin, you're still around? :-) yea. You're right, the LCL became utterly bloated, without a good (discussed and documented) concept. But fortunately it doesn't contain assembler code :-) Efficiency is not normally required in a GUI, the current machines have enough power for themes, transparent windows, and more. But the behaviour of LazSynEdit actually feels a bit like the initial RAD-Studio editor, which also tended to slow down, until a freeze. Check the mem consummation, and swapping (page faults) when it slows. The think is, even if no memory is needed, if it indeed is fragmented, then a lot of the allocate mem may be unusable small, and more be allocated. This also would mean that data that should be together may be located across several pages, forcing more swapping. there are some settings in fpc, top affect the mem mgmt . not sure Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Now I could spot the trouble source: it's fpdoc! DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
On Tue, 24 Feb 2009 05:43:37 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Martin Friebe schrieb: I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Now I could spot the trouble source: it's fpdoc! Why do you think so? Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Graeme Geldenhuys schrieb: I can not work efficiently with Lazarus, due to two problems with the editor (LazSynEdit): it can become dead slow, needing seconds of computation for a single key stroke, and it doesn't support multiple edit windows. This is why I want to contribute to these issues, starting with a working docking manager for multiple edit and explorer windows. Where exactly do you experience those speed issues? If you use GTK1 or 2 you should use a font that is monospaces, and exists in this size for bold and italic too. (And you must not use ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet this can not be compared to other Editors, unless they allow the usage of proportional fonts too, and they too force those into a grid. If it turns out that the slowdown is in code tools, no matter which editor it will be slow (maybe http://bugs.freepascal.org/view.php?id=13039 ?) Is it slow, with none pascal files too? However there is one known problem in SynEdit. The highlighter (turn it off, and see if thinks get faster). The good part is, it does have potential to be improved. Also it should rarely matter. It only happens, if you enter a word that opens, or closes a new fold block (like begin) For me it is not noticeable on 1 Lines file like SynEdit.pp. I can notice it on a 300k Lines file, if I go all to the top, and type begin. There is a delay of a bit over a second, if I press the n. The rest of the typing is not slowed down. If you have any other examples of slowness, please let me know. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: I can not work efficiently with Lazarus, due to two problems with the editor (LazSynEdit): it can become dead slow, needing seconds of computation for a single key stroke, and it doesn't support multiple edit windows. This is why I want to contribute to these issues, starting with a working docking manager for multiple edit and explorer windows. Where exactly do you experience those speed issues? In editing Controls.pp and the related include files. If you use GTK1 or 2 you should use a font that is monospaces, and exists in this size for bold and italic too. (And you must not use ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet this can not be compared to other Editors, unless they allow the usage of proportional fonts too, and they too force those into a grid. The effect is not related to any settings, after startup the editor works fast. It may depend on the number of applied changes or jumps across files or bookmarks, or on the number of symbols in the units, i.e. size of the according (history) lists. However there is one known problem in SynEdit. The highlighter (turn it off, and see if thinks get faster). Okay. I'll also try to close the fpdoc window, it may be related as well. The good part is, it does have potential to be improved. Also it should rarely matter. It only happens, if you enter a word that opens, or closes a new fold block (like begin) The effect is independent of keywords, perhaps it may be related to identifiers and the popup-hints. For me it is not noticeable on 1 Lines file like SynEdit.pp. I can notice it on a 300k Lines file, if I go all to the top, and type begin. There is a delay of a bit over a second, if I press the n. The rest of the typing is not slowed down. The effect is boring, even if I only navigate through the source code with the cursor keys :-( DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: If you use GTK1 or 2 you should use a font that is monospaces, and exists in this size for bold and italic too. (And you must not use ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet this can not be compared to other Editors, unless they allow the usage of proportional fonts too, and they too force those into a grid. The effect is not related to any settings, after startup the editor works fast. It may depend on the number of applied changes or jumps across files or bookmarks, or on the number of symbols in the units, i.e. size of the according (history) lists. If it builds up over time, I am a bit clueless. 2 things I can thing off: - Codetools (but that should not affect scrolling), but Codetools can collect more and more info, using more memory. (AFAIK) - Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). So it may re allocate a lot of Memory. That could upset the memory management. Both are *not* very likely candidates... You can try to reduce the amount of undo steps. Or compile with/withou heaptrc (leak checker) = some people reported that other apps gained speed *with* heaptrc. (But I don't really think it's memory mgmt) The effect is boring, even if I only navigate through the source code with the cursor keys :-( This bit sounds like a problem with painting the window. Which OS / Widgetset are you using? You have not mentioned anything, so I just verify, it is nothing that has become worse since 0.9.26 (or within 2009) ? Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
