Hi,

I was looking at my system processes and noticed that 'startlazarus' is consuming 26.7MB virtual memory & 14.5MB physical memory. Now I'm not 100% sure what the difference is between virtual and physical memory, but either way, it is a lot of memory considering that startlazarus doesn't really do anything serious, other than launch the lazarus binary.

Do other users also see a similar memory usage? If so, why is it such a lot for a rather trivial application?

I'm running Lazarus 0.9.27 (trunk) and compiled with the GTK2 widgetset under Ubuntu (linux) 8.04.2.

Regards,
- Graeme -

Graeme Geldenhuys wrote

but either way, it is a lot of memory considering that startlazarus doesn't really do anything serious, other than launch the lazarus binary.

and show a splash screen.

On windows 32 bits, Mem Usage is 8 MB, VM Size is 5300 KB.

Vincent

Did you strip the debug info ?

Michael.

Michael Van Canneyt wrote

Did you strip the debug info ?

OK, just did that and memory usage is still the same as before.

The file size dropped from 31.7MB (with debug info) down to 5.3MB (without debug info).

Regards,
- Graeme -

Vincent Snijders wrote

and show a splash screen.

Still, does the splash image take up 14MB of memory? For a trivial app, it's a lot of memory.

On windows 32 bits, Mem Usage is 8 MB, VM Size is 5300 KB.

This raises another question though. Why is it that under Linux is uses more than double the memory than under Windows? And yet it is the exact same source code.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I was looking at my system processes and noticed that 'startlazarus' is consuming 26.7MB virtual memory & 14.5MB physical memory. Now I'm not

And to make sure that I am reading the memory usage correctly, I used three different programs.

- Top in a console window
- KDE System Monitor
- Gnome System Monitor

They all show the same values.

Regards,
- Graeme -

2009/7/14 Graeme Geldenhuys :

My startlazarus uses 10M physical memory, while lazarus uses 27M (RES column in `top`). 8M on windows and 10M on linux isn't that far off. It's still a lot, though.

Henry

Henry Vermaak wrote

My startlazarus uses 10M physical memory, while lazarus uses 27M (RES column in `top`).

What widgetset did you compile with? I used GTK2. I guess I can experiment with other widgetsets for the startlazarus project, or is startlazarus a pure console application? (I never checked)

See attached screenshot of my 'top' output:

startlazarus = 14MB physical (26.5MB virtual)
lazarus = 36MB phisical (49.5MB virtual)

I don't care to much about the 'lazarus' memory usage, I think 36MB is quite a little for an IDE. After working with it for a while switching between various project etc. the usage normally climbs to 95MB, which I still think is good for an IDE.

But 'startlazarus' is a lot - considering what it does.

It's still a lot, though.

Thank you, at least now I'm not the only one that thinks so. ;-)

Regards,
- Graeme -

Graeme Geldenhuys wrote

I was looking at my system processes and noticed that 'startlazarus' is consuming 26.7MB virtual memory & 14.5MB physical memory. Now I'm not

OK, so 'startlazarus' is a GUI application. But I also don't see why the splash.pp unit has to pull in the IDE's aboutfrm.pas just to access the LazarusVersionStr constant. So that is already a few extra units (AboutFrm dependencies included) which gets pulled in, and is really not needed.

splash.pp could just as easily read the version.inc file without the help of aboutfrm.pas

Regards,
- Graeme -

2009/7/14 Graeme Geldenhuys :

I'm using gtk2, too. I also agree that the overall memory usage is quite small considering that iceweasel is eating 150M.

Henry

Delphi 7 uses the same amount when designing (150 Mb), and add 50 Mb for each time you run an app in the debugger.

Michael.

executable without smart linking and without wpo
+ stack
+ loaded config files
+ mem fragmentation

A simple lcl app needs 2-4MB less.

FYI: the 95MB is about 50% mem fragmentation.

Yes, it is not optimized for size. Probably one or two MB can be saved. The rest must be done by optimizing the LCL.

Mattias

Two questions...1) Can you defrag memory? I'm running Ubuntu 8.04.2 - if that helps. Or do you just close all apps, logout and then log back in and start all apps again. I tend to run my system for weeks on end without logout or reboot.

2) If I start Lazarus IDE directly using the 'lazarus' executable, I also see a Splash screen. So why does the 'startlazarus' application also have a splash screen? Wouldn't that already save a bit of resources? I guess about 2-3MB maybe.

But then the startlazarus still has to pull in the whole LCL to handle MessageDlg() calls etc... So like you said, if the LCL isn't optimized, the startlazarus can't save much more.

FYI: the 95MB is about 50% mem fragmentation.

Question 1 applies...

Regards,
- Graeme -

Don't worry, I Googled memory fragmentation and found some interesting links. :) It seems that running your system for weeks on end might not be the best idea. Though a close all apps, logout and log back in might help as well.

Regards,
- Graeme -

Debug info is not loaded into mem?

Interpreting Unix memory stats is notoriously difficult. I'd expect more that a certain percentage of the memory space is shared with X/GTK/glibc/threadlib.

What do they say about these values? Most notably, are you 100% sure that all memory regions that are shared are deducted?

Marco van de Voort wrote

What do they say about these values? Most notably, are you 100% sure that all memory regions that are shared are deducted?

I think Mattias hit the nail on the head regarding my system and memory fragmentation. My system had a uptime of 14 days (which is not really that long for my system). I never log out of my system and 90% of the time leave my applications open until the next day back at the office.

Clearly I must have had huge amounts of memory fragmentation for some reason. My system is a P4 2.4Ghz with 1Gig memory. I just got a Lazarus update and thought I would recompile Lazarus for the first time in 3 weeks.

I started the build and went on lunch. When I got back, I was VERY surprised that my system was still busy building the Lazarus IDE. The linker (ld) was using ALL my virtual "swap" memory - 2 Gigs of it, plus 700MB of physical memory. Needless to say my system was at a crawl.

I killed the linking process, rebooted and did the IDE build again. This time it only took a few seconds. I guess I need to schedule reboots more often than once a month (which is my norm). Though saying that, I used to run Ubuntu 7.10 exactly the same way on the same system and never noticed such issues. I'm now on Ubuntu 8.04.2 (upgraded from 7.10 2 months ago).

Anyway, I am a bit off-topic here... My final thought is that 'startlazarus' uses way to much memory for what it does - no matter how you ,
- Graeme -

What's non GUI on a splash ?

Marc

Marc Weustink wrote

What's non GUI on a splash ?

Originally I thought startlazarus just passes parameters on to the lazarus binary and handles the "File > Restart" (and Restart after Build) feature of Lazarus.

But at closer inspection I saw it does splash screen handling and MessageDlg() calls as well, which needs to be GUI. But I'm still confused. When I start Lazarus without the help of 'startlazarus' I also see a splash screen, so why does 'startlazarus' also handle a splash screen? That's duplication of the same thing.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

It is to show the splash screen as soon as possible, not to wait until yet another executable is loaded.

Vincent

Vincent Snijders wrote

It is to show the splash screen as soon as possible, not to wait until yet another executable is loaded.

Well then we are talking about milliseconds really. A splash screen is normally show just after the Application.Initialize call. Surely a few milliseconds shouldn't make a difference - in return for getting the startlazarus a bit "lighter" in memory usage department.

I did a quick test and by removing splash screen support from startlazarus, I managed to shaved off 3-4MB of memory usage. It went down from 14MB to 10MB memory. I'd say that is worth the few milliseconds extra it takes for the Lazarus executable to show its own splash screen.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

If you want to trade speed for memory, it is better to rewrite startlazarus to exit after it has started lazarus.

Vincent

Can you test and verify the few (<10) miliseconds claim on windows, with it notorious slow process start up?

Vincent

Please test on first run, when the OS has to load the lazarus exe from disk.

Mattias

Vincent Snijders wrote

Can you test and verify the few (<10) miliseconds claim on windows, with it notorious slow process start up?

OK, I'll test tomorrow at work in my Windows VM session. I don't have Windows at home to test now.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Vincent Snijders wrote

If you want to trade speed for memory, it is better to rewrite startlazarus to exit after it has started lazarus.

I did not look at the Lazarus IDE code yet, but I thought startlazarus must stay in memory for the "File > Restart" support and the "Restart after Build" support?

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

No, both options work (but a bit slower) even if you just did ./lazarus

Vincent

A splash screen mostly _IS_ for the odd cases, rather for the case where it all goes fine. E.g. when an unstripped lazarus bin is on a network share it can take long.

ya know... i guess being so much old school as i am but i still fail to really understand why a "splash screen" is really necessary for much of anything... especially if it causes the app to consume a lot more memory than truly necessary...

then again, i look back over the recent posts and i see comments like "10ths of seconds compared to megs of RAM usage" and i stop and really wonder where has all the reality gone... that meaning who quibbles over a few Meg of RAM when surely less than 1 Meg is really necessary... :?

and then i stop and look at the mess that GUI apps have to deal with and how much memory they consume just to be able to draw one tiny "hello world" box on any OS screen with a stupidly simple "close" button... but i still wonder where everyone went and why they all decided to stop efficient and "bikini" (meaning short and to the point) coding and instead have fallen on the wayside with all the others and are now coding simple apps that somehow turn out to be way over bloated for one reason or another :? :(

signed, too old school to understand and keep up with the new way of life :? :(

2009/7/15 waldo kitty :

Get real, please. In order to wrap the underlying complexity of widgetset apis into a nice object oriented interface that you can use to make your nice gui interfaces in a sane, readable, maintainable fashion, some price will have to be paid. In order to do this in a platform independent way is even harder, and will incur even further penalties.

Nothing stops you from writing your app in bare widgetset calls, but then you lose some/all of the above-mentioned advantages you have with lazarus. Ram and disk space is cheap, and lazarus uses less memory than delphi 7 (don't even mention the later offerings).

Also read the "size matters" document on the wiki, before you complain about that.

Henry

waldo kitty wrote

ya know... i guess being so much old school as i am but i still fail to really understand why a "splash screen" is really necessary for much of anything... especially if it causes the app to consume a lot more memory than truly necessary...

A splash is a GUI embellishment, sure, but it does have a function. It shows the app is running, and thus avoids multiple starts, and uncertainty if it is running from the side of the user.

And essentially the whole GUI is redundant, we could just feed the program a textfile :-)

Bloated is a subjective value, and as such meaningless. The whole issue is cost vs productivity, and with the current low cost/MB, and the increase in productivity of frameworks, the balance tips in that favour of productivity and managability. And the LCL is fairly small even to most contemporary frameworks (.NET, JDK COCOA)

That is also why sometimes a couple of units more than strict necessarily are linked into startlazarus. Periodically reviewing and maintaining this (and the breakage resulting from it) is time consuming, and 99.9% of the users won't even notice.

signed, too old school to understand and keep up with the new way of life :? :(

I'd rather say too much reacting on emotion, and not trying to drill down to what is really happening. The quoted figure of memory use is not even sure.

One also step over source/project management issues to easy hoping for an easy quick fix.

I think the following section of the size_matters faq sums it up quite nicely

http://wiki.freepascal.org/Size_Matters#Unrealistic_expectations

And don't forget to need the text in a friendly bold typeface.

waldo kitty wrote

ya know... i guess being so much old school as i am but i still fail to really understand why a "splash screen" is really necessary for much of anything... especially if it causes the app to consume a lot more memory than truly necessary...

I used to think a little like that, but recently I added a splash screen to my application and a whole host of users were much happier.

My application populates a directory tree while it's loading. On systems with slow network links this can take a significant amount of time (up to 25 seconds on OSX over a slow network to an SMB server). Fstat calls seem to be quite expensive on OSX compared to linux, particularly over the network.

Putting a splash screen up stopped all the complaints of "It takes _ages_ to load". The funny thing it is takes precisely the same amount of time to load to a point of fully functional now, but the users all said "Wow you sped up the loading *heaps*". It's a little psychological I guess. The splash screen pops up very quickly and that seems to keep people placated while the slow stuff happens. I don't even have a progress indicator or anything "flashy, smelly or dangly" for them to look at.

Also, on OSX, the act of displaying the screen and polling the application event loop stops the app icon bouncing in the dock, so it looks like its loading faster there also. (An unexpected side effect)

Brad

That's true. But instead of a cheap splash screen I would expect such applications to give some information about *what* it is doing (while doing it). Of course, it costs more time to code but to me it shows that the programmers take care of the users.

It's mostly loading from disk. After first start when the OS has all in its cache the IDE normally starts in a second. So most of the time the splashscreen waits for the OS to load the executable. IMO this is not a very helpful information, so it is not (yet) written to the splashscreen.
Of course when the system is busy or the config files are on a slow network share, then even reading a small xml file can take a long time. So far I think this is too uncommon to implement a progress bar for that.
If you have enabled the option to auto open the designer forms, then opening a project can take some time. This option is on by default to impress people (aka newbies). I normally turn it off.

Mattias

Also, on OSX, the act of displaying the screen and polling the application event loop stops the app icon bouncing in the dock, so it looks like its loading faster there also. (An unexpected side effect)

An existing and visible (foreground) window may increase the process priority or other scheduling factors, on every system. Like HTTP typically has higher priority than FTP. Only a wild guess, dunno about concrete details.

DoDi

No, on OSX the dock icon sits and bounces until the application polls the carbon event loop the first time. The application.processmessages that is required to get the splash screen to draw properly does this and therefore stops the dock icon bouncing a lot earlier than if it waited for the main form to finish loading.

The load time from click to usable is identical in each case. One shows a splash screen and the other just sits there with a bouncing dock icon until the main form comes up. I know which one I prefer.

I'm not really familiar with OSX development, so it was just a nice bonus for me :)

Brad