[Lazarus] RFC: remove StayOnTop for splash screen

Mattias Gaertner nc-gaertnma at netcologne.de
Tue Mar 2 16:11:17 CET 2010


On Tue, 02 Mar 2010 14:50:18 +0100
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Martin schrieb:
> 
> >> IMO the IDE should use an cache for the SynEdits, that must contain at 
> >> least the currently active text file. More opened files can be parsed 
> >> and added to the cache later, when they are really activated. When the 
> >> systems runs out of memory, old entries can be removed from the cache. 
> >> Inactive files can be parsed in the background, when the system is idle.
> > 
> > Well there are 2 option. Actually both can exist at the same time.
> > 
> > 1) SynEdit scanning on idle. I had that idea for a long time already, 
> > but a lot more needs to change in SynEdit, before this can be done.
> > 2) The IDE only opening a tab, and defer creating the SynEdit. I haven't 
> > looked into this.
> 
> With multiple editor windows, the files must be kept (and parsed...) in 
> their own pool, separate from the SynEdit viewers.

Why do you think this is needed?
AFAIK I'm the only one that has provided some profiler output and it
showed that the synedit scanner is not a big number. The bigger
limitation is the visual controls (pagecontrol, pages).

 
> > Then again. My PC is about 3 years old, with an average of 10 - 20 
> > SynEdits, it takes 1 to 2 seconds of parsing. Opening a 100 files on 
> > loading of the IDE may be a legitimate action, and may have good 
> > reasons, and certainly can be justified by personal choise => but how 
> > many people are affected by it?
> 
> That depends on the meaning of "open". The filenames can be imported 
> from a project or desktop layout file, into the file pool. Actual 
> loading can be deferred until the files really are required in the IDE.

"Open" is here: in the source editor.
Of course the IDE handles hundreds or thousands of files in the
background.

 
> Even if newer machines have enough power to process a huge number of 
> files within a few seconds, I'd take care for users with old equipment - 
> who else would do, if not Lazarus? Virtual machines also can have less 
> RAM, and performance can become very poor once such a system starts 
> swapping.

The source editor mem to disk ratio is about 1:6. For example opening
5mb (150kloc) of sources needs 30mb of RAM.

 
> > Caching, and removing? why re-invent the wheel. It has a similar effect 
> > than the OS doing swaping memory to swap-file...; And you have to keep a 
> > copy of all open files, just in case they get modified on disk, while 
> > they are in memory.
> 
> When the user has not seen an file already, it doesn't matter whether it 
> was modified on disk. Whenever a modified file becomes active in the 
> editor, the user should be asked whether the file should be reloaded, so 
> that parsing of inactive files may be a waste of resources.

They are parsed only once and only because the user wanted the file to
be open in the source editor. I still see no reason why someone wants
to always open a hundred files in the source editor.

 
> > Also having looked at the gprof numbers, the time seems to be lost while 
> > assigning the keycodes. Which seems to be done in a very inefficent 
> > manner. My guess is that the IDE-defaults/user-configs are merged with 
> > the SynEdit defaults, and during this probably each code is tested for 
> > existence (looked up) first, before potentially being added. Given that 
> > there are 100of key combos, which have to be iteraded a 100 times (and 
> > this is for each synedit...) => well (rather not so well).
> 
> I just don't understand what you mean. The SynEdits should *perform* 
> edit commands, but the *detection* of keycodes is the job of the 
> framework (IDE).

It does for other commands. And since synedit already can handle
keys on its own, the IDE just tells synedit which key code should do
what.

 
> > It get's on the todo list now (but little priority). Maybe creating just 
> > one merged list, and then simply clear+copy for each synedit.
> 
> That's a wrong approach, IMO.


Mattias




More information about the Lazarus mailing list