Hello guys,
what do you think of removing the fsStayOnTop flag for the splash screen? It serves no purpose and is very annoying...

Best regards,
Fl?vio

Hello guys, what do you think of removing the fsStayOnTop flag for the splash screen? It serves no purpose and is very annoying...

+1

I already had removed the splash screen, because it was hiding error messages/dialogs on Lazarus start. It also happens to appear on the wrong monitor, when the IDE (mainbar) is configured to reside on an different monitor (but that's liveable).

DoDi

2010/3/1 Fl?vio Etrusco :

what do you think of removing the fsStayOnTop flag for the splash screen? It serves no purpose and is very annoying...

Agreed.
It's better to speed-up loading, rather than masking it with all kind of splash screens.

thanks,
dmitry

That's another story. I'm not proposing to remove the splash screen (actually Paul taught there's already a parameter or setting to remove it. i'm proposing is simply to remove the stayontop, which serves no purpose...
The delay seems to be caused by codetools loading the files...

Best regards,
Fl?vio

Thankfully another person running with multi-monitor. I know who to ask for suggestions when I start hacking it ;-)

-Fl?vio

The parameter to not show the splash screen is:
--no-splash-screen
or
--nsc

There are two splash screens.
One in the IDE and one in the startlazarus executable. The on in the IDE hides as soon as a modal form pop ups (e.g. error message) or the IDE is ready.
The other in startlazarus stays for some seconds. startlazarus tells the IDE to not show its splashscreen. There is no communication between both.

> Agreed. > It's better to speed-up loading, rather than masking it with all kind > of splash screens.

+1

Why do you think so?

Mattias

I guess you're asking about the codetools part? TBH it's a wild guess. It takes much longer when the active project is Lazarus and I have several files open and it's waaaay faster on warm reload/the files are cached.

-Fl?vio

Mattias Gaertner wrote

> The delay seems to be caused by codetools loading the files... Why do you think so?

Codetools is an ideal piece of Lazarus to shift the blame on.

Best regards,
Paul Ishenin.

Maybe you have enabled Form editor / open designer on open unit?

When I start the IDE with a hundred files open then I get the following from gprof. As you can see codetools is hardly measurable. It is as expensive as loading the splash image (less than 2%). Synedit needs some optimizations.
Please test too and see what you get.

6.94 0.10 0.10 7717033 0.00 0.00 SYNEDITKEYCMDS_TSYNEDITKEYSTROKE_$__GETCOMMAND$$TSYNEDITORCOMMAND 4.86 0.17 0.07 CLASSES_TFPLIST_$__GET$LONGINT$$POINTER 4.17 0.23 0.06 SYSUTILS_COMPAREMEMRANGE$POINTER$POINTER$LONGWORD$$LONGINT 3.47 0.28 0.05 7717033 0.00 0.00 SYNEDITKEYCMDS_TSYNEDITKEYSTROKES_$__GETITEM$LONGINT$$TSYNEDITKEYSTROKE 3.47 0.33 0.05 FPC_ANSISTR_SETLENGTH 2.78 0.37 0.04 LAZ_DOM_TDOMNODE_$__FINDNODE$ANSISTRING$$TDOMNODE 2.08 0.40 0.03 863797 0.00 0.00 SYNHIGHLIGHTERPAS_TSYNPASSYN_$__NEXT 2.08 0.43 0.03 268090 0.00 0.00 SYNHIGHLIGHTERPAS_TSYNPASSYN_$__KEYHASH$$LONGINT 2.08 0.46 0.03 FPC_PUSHEXCEPTADDR 2.08 0.49 0.03 fpc_ansistr_decr_ref 1.39 0.51 0.02 237132 0.00 0.00 SYNEDITTEXTTRIMMER_TSYNEDITSTRINGTRIMMINGLIST_$__GET$LONGINT$$ANSISTRING 1.39 0.53 0.02 319 0.06 0.53 KEYMAPPING_TKEYCOMMANDRELATIONLIST_$__ASSIGNTO$TSYNEDITKEYSTROKES$TCUSTOMFORMCLASS 1.39 0.55 0.02 CLASSES_TCOMPONENT_$__NOTIFICATION$TCOMPONENT$TOPERATION 1.39 0.57 0.02 CLASSES_TLIST_$__GET$LONGINT$$POINTER 1.39 0.59 0.02 CLASSES_TLIST_$__GETCOUNT$$LONGINT 1.39 0.61 0.02 CWSTRING_CONCATCHARTOANSISTR$CHAR$ANSISTRING$LONGINT 1.39 0.63 0.02 CWSTRING_UPPERANSISTRING$ANSISTRING$$ANSISTRING 1.39 0.65 0.02 FPC_SETJMP 1.39 0.67 0.02 FPIMAGE_TFPCUSTOMIMAGE_$__SETCOLOR$LONGINT$LONGINT$TFPCOLOR 1.39 0.69 0.02 FPREADPNG_TFPREADERPNG_$_DODECOMPRESS_DECODE 1.39 0.71 0.02 SOURCELOG_TSOURCELOG_$__BUILDLINERANGES

Mattias

I would guess that it is many parts of the IDE.

If you open a project with many open sources (many open editor tabs) then SynEdit will take it's share of time too. That is at least if the files are large, since the highlighter scans them all for their fold structure.
You could see this on older versions of Lazarus, as each source editor was shown for a tiny moment, before the next was displayed. The unnecessary display was removed, the scanning takes still place.

However, this is only a small part of the loading time.

Martin

I'll try to run with gprof, thanks. Also in next time I make such claims ;-) FTR: No, I have "open designer on open unit" disabled. Did you try this on without files being in cache?
Guess I'll have to do some work in SynEdit then. It used to be my area of expertise after all ;) But the code in Lazarus is a (almost) completely different beast, and maybe not much can be done with codefolding wihout making some concessions...

Best regards,
Fl?vio

Zitat von Fl?vio Etrusco :

When the files are not in the OS cache, then measuring with gprof does not make much sense.
The biggest thing is to load the 100mb lazarus executable. And if you start lazarus for the first time after installation, then the IDE scans the FPC source directory, which might take quite some time on slow disks or even worse on network file systems.

Guess I'll have to do some work in SynEdit then. It used to be my area of expertise after all ;) But the code in Lazarus is a (almost) completely different beast, and maybe not much can be done with codefolding wihout making some concessions...

Mattias

Well, my issue was not that codetools is slow or lazarus start is slow, is that the splash screen should not be stayontop ;)

Fl?vio

Guess I'll have to do some work in SynEdit then. It used to be my area of expertise after all ;) But the code in Lazarus is a (almost) completely different beast, and maybe not much can be done with codefolding wihout making some concessions...

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.

DoDi

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.

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?

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.

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).

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.

Best Regards
Martin

I just opened 219 files, which took 6 seconds. The synedit scan takes less than a second. Half the time was spent in gtk/X handling the tabs.
I think there is no need for an idle scan.

2) The IDE only opening a tab, and defer creating the SynEdit. I haven't looked into this.

Yes, that could save a second. wow. ;)

I don't see how people can navigate a hundred files. Lazarus has only shortcuts for the first ten. And for the window menu you need a big screen with a tiny font.

I did that. Now it does not appear in gprof any more. Saves a few percents. I doubt someone will notice.

Mattias

Mattias G?rtner wrote

The biggest thing is to load the 100mb lazarus executable. And if you start lazarus for the first time after installation, then the IDE scans the FPC source directory, which might take quite some time on slow disks or even worse on network file systems.

I solve this problem very easy - I add -Xg option to the build script and my Lazarus executable is just 11Mb after - it loads very fast.

Maybe we can change our makefiles to use -Xg by default for IDE building?

Best regards,
Paul Ishenin.

With multiple editor windows, the files must be kept (and parsed...) in their own pool, separate from the SynEdit viewers.

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.

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.

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 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.

DoDi

Can you (people) stop hijacking my thread? :-P

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?

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.

... 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

(Now I'm lost)

Best regards,
Fl?vio

I don't see how people can navigate 5+ files in default Lazarus setup. Hence the reason I have vertical tabs setup in Lazarus+GTK2 - my own custom hack. This allows me to easily navigate up to 20 files on a 1440x900 resolution screen. Much better than the previous 5 tabs and then horizontal scrolling occurs. :-(

Can't we implement vertical tabs by default to platforms that support them? I know Windows can't because they use this pretty dumb idea of making text vertical too. Maybe a custom written/drawn LCL PageControl is needed for IDE use only - then all platforms can enjoy the benefit vertical tab layout gives?

Screenshot of tabs on right.

http://opensoft.homeip.net/~graemeg/laz_notebook_right.png

Regards,
- Graeme -

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).

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

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

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.

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

Or maybe use a treeview so the open files can be grouped, for example by directory or files in the project, files in a package, ...

Mattias

I don't see how people can navigate a hundred files. Lazarus has only shortcuts for the first ten. And for the window menu you need a big screen with a tiny font.

The many include files are a mess, WRT editor notebook(s). I already thought of a two-layer structure, with the units in the top layer notebook, and all related files in another sub-notebook. No problem with freely dockable tabs, once the IDE is refactored to know about an ActiveSynEdit as the currently active document :-)

DoDi

The files must be parsed (for highlighting) within the overall SynEdit. But, this parsing must move from the "viewer"/"display" part to the "content provider" part. Otherwise if you view the same source twice (and both views use the same highlighter), then the text would be scanned twice, even though once would be enough.

Anyway, that has been iterated last year, under the topic Model-View-Controller.... So lets not go there

Martin

Hello Lazarus-List,

Tuesday, March 2, 2010, 2:54:05 AM, you wrote:

MG> I did that. Now it does not appear in gprof any more. Saves a few MG> percents. I doubt someone will notice.

My experiences with gprof in Windows shows me that it is almost useless for this kind of tests. As it is a pooling tracer it must take a lof of "snapshots" to get a clear picture of a process, so it must be repeated for many time, like several minutes. Tracing operations that involves only a few seconds results in a non real time distribution which will change a lot simply by removing or adding one line of code.

Is there any invasive tracer that can be linked with fpc/lazarus ?

I use it under Linux with lot of success for single threaded apps. It takes one hundred samples per second and does not slow down the program. You need at least a few seconds of computation and you can ignore anything that takes less than 0.1 second.
Beside the samples it also shows the number of each call and who calls whom. So if a function was called more often than expected you know what to fix.

Is there any invasive tracer that can be linked with fpc/lazarus ?

valgrind.

see here
http://wiki.lazarus.freepascal.org/Profiling

Mattias

Hello Lazarus-List,

you wrote

> that involves only a few seconds results in a non real time > distribution which will change a lot simply by removing or adding one > line of code.

MG> I use it under Linux with lot of success for single threaded apps. MG> It takes one hundred samples per second and does not slow down the

Yes and you have a lot of possibilities that the sample takes in an fpc_movememory function :) But a 2 or 3 seconds process is too small for gprof.

MG> Beside the samples it also shows the number of each call and who calls MG> whom. So if a function was called more often than expected you know MG> what to fix.

Call sequence is statiscally propagated and when recursion happends it could becomes crazy... Anyway it is more than nothing for sure :)

> Is there any invasive tracer that can be linked with fpc/lazarus ?

MG> valgrind.
MG> see here
MG> http://wiki.lazarus.freepascal.org/Profiling

Yes on Linux I know (but not used) valgrind, but for windows ? I think no, so us will no go more off topic ;)

> With multiple editor windows, the files must be kept (and parsed...) in > their own pool, separate from the SynEdit viewers. Why?

Because no file can be assigned to a single SynEdit.

Where's the problem?

DoDi

A List- or ComboBox would do that everywhere. Since the pages are all of the same type (SynEdit), it's not necessary to use complicated paged controls for the documents.

DoDi

> 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?

For simplicity, when multiple SynEdits can show the same file.

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).

In a simple approach the controls should not have any impact on the performance. Since the tab clients are all of the same type (SynEdit), a single (visible) client control and a separate tab control would be sufficient. When multiple SynEdits are required, all but the active one can be hidden (see my notebook-docking approach).

What's the difference?

That looks acceptable, also on small systems.

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.

Me2, but I frequently found 30+ open files when exploring the Lazarus project. When the tabs are not closed manually, they will be reopened at the next start.

That's not in accordance with MDI nor MVC. You oberserved the overhead yourself, that results from a deviation from accepted designs.

DoDi

Mattias Gaertner wrote

Or maybe use a treeview so the open files can be grouped, for example by directory or files in the project, files in a package, ...

For me at least, it isn't important to know if units are in different directories or packages instead of project. The important part is easily getting to the opened files, reordering them etc.

OpenUnitFiles.lpk does all of this already. Maybe it can be integrated and replacing the PageControl. Embed the 'Open unit files' dialog into the editor window on the right, and remove PageControl completely, or hide the tabs. Then we have the best of both worlds.

* Vertical display of open files on all platforms.
* Quick search feature to find open unit
* Reordering of files by simply draging them up or down

The only reason I'm not using OpenUnitFiles.lpk by default is because it's a separate window and duplicates some information already displayed by the PageControl. But having this as part of the editor window and replacing the tab would be brilliant. :)

If you haven't seen that add-on package yet, here is a screenshot of it attached.

Regards,
- Graeme -

Hans-Peter Diettrich wrote

A List- or ComboBox would do that everywhere. Since the pages are all of the same type (SynEdit), it's not necessary to use complicated paged controls for the documents.

Yes, a listbox will work perfectly and something like that already exists. See my reply to Mattias.

Regards,
- Graeme -

Hmm, this could save some time. I never compared tabcontrol with synedits and pagecontrol with synedits. Can you create a test app and time the results? Then we know, if it is worth the effort.

1. some minors like the IDE warns if it is not a text file.
2. forms are loaded if the options are enabled
3. a synedit is created
4. a page is created

The last point is what Martin and me don't understand. Why not close files? Who needs this optimization?

30 files costs a second. Big deal.
The optimization is needed when you open a hundred files on a slow system. Who needs this?

The overhead is (or was) a one time initialization function that costed for 100 files 0.15 seconds. That's why it was not optimized.

Mattias

Yes.

Mattias

An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100303/b1a5a1e9/attachment.html>

Or add "file" level to the existing Code Explorer treeview. That would have additional benefit of allowing to navigate to both another unit _and_ another class/procedure inside of it with a single click.