Can you (people) stop hijacking my thread? :-P On Tue, Mar 2, 2010 at 10:50 AM, Hans-Peter Diettrich <[email protected]> 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.
3) SynEdit defer the parsing of files until they are shown. 4) All options above. Actually I don't think 1 is necessary if the bottlenecks are found. > With multiple editor windows, the files must be kept (and parsed...) in > their own pool, separate from the SynEdit viewers. Why? >> 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? We should make this better. Martin Waldenburg would die in disgust if he reads this hehe > > 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. Deinfetely. > 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. > > >> 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. > > >> 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). > ... ok. > 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). > Yeah. But we must implement two/multiple keystroke ActionList handling. Maybe creating just >> It get's on the todo list now (but little priority). >> one merged list, and then simply clear+copy for each synedit. > > That's a wrong approach, IMO. > (Now I'm lost) Best regards, Flávio -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
