[Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]

[Martin Friebe]

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