Slashdot Mirror
Understanding Memory Usage On Linux
Percy_Blakeney writes "Have you ever wondered why a simple text editor on Linux can use dozens of megabytes of memory? A recent blog posting explains how the output of the ps tool is misleading and how you can get a better idea of how much memory a process really uses."
Nice article. /dev. For example, the X server, on a system with a 256MB graphics adapter, will map all that memory into its address space, making X look huge, even though it's not using all that much system RAM. This will show up as a device-backed mapping in the maps file.
It could also have mentioned mappings on
On a related note, X also looks big because it's holding pixmaps belonging to various applications (Firefox comes to mind).
Have you been here? http://dbaron.org/log/2006-01#e20060114a
p rogress/#comments
and helped do something about it?
Also see here
http://www.squarefree.com/2006/02/04/memory-leak-
about progress made and being made.
The Singularity is closer than you think
Quant
How can they diminish EMACS like that ?
'top' gives you stats on what percent use programs make of memory and cpu.
Even so, it isn't perfect. Something will bog down my machine, I will run 'top' and discover that no process is using more than 10% of the available resources. OK, so why is my machine bogging? I guess there's no perfect tool.
So, people don't know how to interpret the output of ps? And that's a Slashdot frontpage story? What have I done wrong in my settings to deserve such trivial items?
Try statically linking a program that uses just a few glibc calls and it's pushing 800k. Now add in libc++, Qt/gtk, Xlib, kde, boost, xml, etc and you're talking a lot of memory. This is what gets me about people who say "well Java performs okay now, but it uses so much memory".
A typical C/C++ based app uses just as much memory, it's just shared between processes. And for that matter, startup time of the first thing using kde/gnome isn't all that great either. Isn't it about time some effort was put into making Java or Mono part of the system, so it can be shared like C apps do?
How about going one step further than just blogging about it and actually submitting a documentation update to the ps man page. That way future confusion of the ps output could be avoided. Of course I guess people have to actually read the man page (In honor of slashdot, I didn't read it before posting this comment ;-)
If you wanna see a real OS with memory hogs, run Emacs...
Linux (and to be fair, Unix-like systems in general) shine at file & memory management. Many people don't know, but executable files are not 'loaded' in the Windows sense - they're just mapped into memory. This design improves performance and gives the system better performance under swapping (not thrashing, mind you). Things like mem mapped files are integral in the way the system is designed and implemented. That's one of the very reasons why a Linux machine usually runs faster and more reliable than a equivalent Windows machine... even if has less memory. The Apache tuning example is great, and it shows how much performance you can squeeze out of a good design.
Firefox does indeed suffer from some very serious memory management-related issues. For anyone who doesn't have an ideological connection to the project, it's obvious why that is.
About 8 months back I attempted to embed Gecko within an existing graphical user interface toolkit. Having heard so much from the open source community about how easy it was to do, I thought it would go rather quickly. Of course, it did not. The lack of up-to-date documentation (if such documentation there at all) and solid examples were some of the big problems.
But the overall architecture struck me as the worst part of Mozilla. Like it or not, it's overly complicated and convoluted in many areas. I admit that it's not easy to build well-designed software, but they so completely missed the boat it's unbelievable. However, it does make it obvious as to why many people complain about Firefox and Seamonkey running so slowly, in addition to suffering from huge memory consumption.
As for the embedding of Gecko, I said to hell with it. I took a page from Apple, and used KHTML instead. The loss in portability by not going with Gecko was well worth the far quicker development time, the lower memory consumption, the increased responsiveness, and the higher degree of stability of KHTML.
Cyric Zndovzny at your service.
Devin's blog also has an excellent posting on Apache performance. "Tuning Apache, part 1" (and the comments) is the sort of succinct empirical advice it is always nice to find.
Typical Slashdot response, blame the users for the browser's bloat. 99% of the users of Firefox are not programmers and wouldn't have the slightest clue what is going on. They just want to look at porn without popups or getting infected with spyware via IE's ActiveX vulnerabilities. Asking them to download some script, set environment variables, and then file bug reports is unrealistic since most of them can't even tell the difference between a web browser and a web site. That's what beta testers are supposed to be doing but we all know that 90% of the beta testers never bother to file any bug reports, even when the browser crashes.
Have you ever wondered why a simple text editor on Linux can use dozens of megabytes of memory?
No. I use ps and... oh.. OH... who passed this 08/15-user-FUD-article?
All those shared libraries are also part of the reason that KDE and GNOME can take so long to start up, and why more memory and a higher-RPM hard disk can speed things up. It does make me laugh sometimes that Emacs is now one of Linux's fastest-starting desktop apps.
First of all, I wasn't embedding Gecko into a GTK+ application. Had you bothered to read my post, you would have seen that I was embedding it into another toolkit. So using GtkMozEmbed outright was for the most part out of the question. I didn't want to involve any more unnecessary code than I had to.
Second of all, it doesn't serve as a good example. Look at the code yourself. It's horribly convoluted. While it does indeed provide a fairly usable interface to the programmer who is using it, what's under the hood is an utter mess. That's directly caused by the poor design of Gecko itself.
Cyric Zndovzny at your service.
Indeed. You're completely correct. If the Mozilla crew want to take on Internet Explorer, then they can't have the general public debugging their software for them. That just won't fly.
Part of the problem is that it's far too easy for bugs to creep into Mozilla. The code is a small step above horrible, and the architecture isn't much better. A lack of up-to-date documentation leads to programmers not knowing which XPCOM interfaces are deprecated, and which aren't.
You can look at browsers like Konqueror and Opera, which offer a very comparable feature set to Firefox, yet do no suffer from the drawbacks. Not only that, but Konqueror and Opera are often described as feeling far more responsive, while being extremely stable. It's things like that which really impress the average Jill and Joe. Excessive memory usage will just perplex them, and likely result in them going back to Internet Explorer.
Cyric Zndovzny at your service.
The whole discussion should be grounded in the reality of alternatives. A typical M$ system will grind it's way into swap space on start up, before the user loads anything! The very latest and greatest Linux distros run well on Pentium IIs and the like, which XP refuses to install on.
Friends don't help friends install M$ junk.
I'm kinda curious who you heard that from. Embedding Mozilla when you've got an already existing binding (such as for Gtk) is trivial, but writing the binding from scratch is no easy task. Gecko is a beast and the need to integrate its own drawing layer with yours makes it hard to integrate as an embedded browser. In its defense, it was never designed or intended for such a purpose. KHTML is only easier if you're using Qt (and you *did* obey the license, right?), otherwise you need to provide mappings from all the Qt primitives used by KHTML to your own. Easier than embedding Gecko, but still not trivial.
http://en.wikipedia.org/wiki/Windows_NT
But hey, 10 processes are using 10%...
Look, right across the board, eleven, eleven, eleven and...
And then have a lot of processes attach to those chunks of shared memory.
:-P
It's kind fun to see your 4 gig machine have processes using 100+ gigs of RAM on it because there are 50 processes attached to a 2 gig chunk of Sys V shared memory.
And it's even more fun when a noob admin notices it and gets management all spun up over "the huge memory leak" the overexcitable twit found in your apps.
What I really wanna understand is the memory usage in Windows.
w00t
A nice article, been looking for more information on this. So often you read items in program FAQs or such giving a disclaimer on how ps memory usage is misleading, but they offer no better way. Okay, so ps memory usage information is pratically useless; now what am I supposed to use?
I was hoping for a bit more, though; like, say, a small program that lets you see both the aggregate virtual memory total as well as the memory used specifically by the program. Add a few options for how to handle the only-one-app-using-a-library situation. Doesn't seem like it'd be that hard, and very useful.
The JVM serving this page currently has an uptime of 32 days. But in the past it's had uptimes of over 200 days. Neither it, nor any of the other Tomcat servers I run, has ever gone out of whack. Java (Tomcat, Weblogic and others) powers the web servers of many of the world's biggest websites, serving millions of pages of dynamic content every day. If it was unreliable, that wouldn't be happening.
I'm old enough to remember when discussions on Slashdot were well informed.
I beg to differ
Of course. EMACS - eight megabytes and constantly swapping.
Because there is nothing quite like seeing you've got 20 Oracle instances at 1gb each on a 4gb box. :)
You will notice how much faster Konqueror is on a low-end machine. I'm currently playing around with a so called 'thin client', which mostly suffers from having less memory (256mb), a not too fast cpu (800mhz via p3 compatible) and little storgae (128mb). The cpu and memry matter for a browser.
Now, I can run either Firefox or Konqueror on this machine, in both cases without needing swap. Both will slowly grind to a hold after a couple of hours of intensive use due to running out of memory. No idea if it is Konqueror or some other kde component that it uses, but it seems there is little difference between the 2 when it comes to slowly wanting to eat more and more memory.
Konqueror renders a lot faster, and stays more responsive, untill the moment a page tries to use some kind of javascript. When pages do, Firefox just goes on, being slightly sluggish just like it already was, while at times Konqueror grinds to a virtual halt for a few secs, and is slow as hell untill another page gets loaded. Doesn't always happen, but often enough to prevent using it.
And yeah, I got both of them installed, but not on the 128mb internal storgae, both come from an external usb conencted disk.
On a related note, if anyone is curious how memory management library calls such as "malloc" work, you might check out my article on the subject.
Engineering and the Ultimate
The architecture of Java doesn't allow it to share library memory space like this. The effect of this is Java programs, appear to use about the same amount of memory as compiled programs when, in fact, they are using quite a bit more. This is why running a Java program that takes up 25 megs of memory can seem to suck the life out of a computer while a compiled executable using 25 megs doesn't. Java is probably really using about 10x more memory.
It's also why systems running a Java framework with multiple programs executing in the same Java process do so much better than ones where everything is in its own process. This is Java's sweet spot, where these JVM architecture disatvantages have the least impact.
This is my understanding of how Java's libraries work. Someone let me know if I'm missing something here.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
Run top. Check out the column that says SHR. Subtract it from VIRT if you want to know the virtual memory usage of a process excluding shared libraries, or subtract it from RES if you want to know the physical memory usage of a process excluding shared libraries. Problem solved.
I don't like how he phrases that what ps reports is "wrong." It's not wrong, or even "wrong." It reports exactly what Linux tells it (through the proc filesystem). It's just might not be what you expect it to be, which means you don't understand the tools and the system. When ps reports that a process' virtual memory usage is xKb, that is correct. In the address space for the process, xKb have been allocated. Shared or not, they're still in the address space.
The first person to use a system might load 128Mb worth of libraries and applications. The second and all subsequent users may only use 15-30Mb worth of RAM for each additional user. e.g. A 1Gb RAM system could handle 30 concurrent users rather than 8.
Deleted
>> Have you ever wondered why a simple text editor on Linux can use dozens of megabytes of memory?
Correct me if I'm wrong but... doesn't the fact that KEdit uses a lot of libraries that consume resources and impact system performance -- whether shared or not -- still means that it is a hog? I mean, if a seemingly simple application is consuming "dozens of megabytes of memory", saying "oh, it's OK, because most of it is being shared and already commited", does not really excuse it. What if those libraries are not currently being used by any other process?
In order for the shared memory to lessen the impact on the system, the user must be running some other processes that share the same libraries. This to me is a *BIG*, and unwarranted, assumption by the developer, as evidenced by his example of someone running the Gnome environment but running a single KDE application.
-dZ.
Carol vs. Ghost
When doesn't CyricZ troll /. and other places. look at his history of posting. LOL LOL
The story should really be "Why doesn't ps give human readable output by default?"
If the knowledgeable system admin wants the output the way it is now, he can just modify it - ps -auxgiveittomebaby and get what he wants.
However, this still does not excuse a text editor for having a 25MB footprint!
When that editor runs it WILL require 25MB of memory to run (well, the working set may be a little smaller, but if we don't want any paging we need the full 25MB).
The "oh well its only shared libraries" excuse is just that - an excuse. Admittedly, the fault may not be with the author of the text editor application but more with the hyper-bloated "desktop" that he links to his application -- however, he should be aware of the implication of using those bloated desktop libraries, and probably do a bit more work to avoid their use.
The thrust of the article should not have been to excuse the size of those applications because "they are only shared libraries", but to make developers, particularly desktop developers ashamed of the bloated, slow systems that they produce -- seemingly in a never ending attempt to make Windows look fast and lightweight.
The thing is, when you fork it maps the memmory and marks everything as copy on write, when something needs to write to part of the memmory, then it will make the copy for each process.
A couple other tips:
* Each thread in a process shows up as consuming the same amount of memory (either this only happens under Linuxthreads or I don't have any threaded applications running on my system).
* Device mappings show up as consumed memory (which generates plenty of XFree86/xorg complaints). If you want to find out how much memory xorg/X11 is actually using (bytes in cached pixmaps on behalf of each process and sans device mappings), try this program (contains a tiny program that lists how much memory X is using for other programs by caching pixmaps and a perl script that lists how much memory X is using sans device mappings).
* The article mentions the fact that shared libraries show up in every application's memory usage. So, for example, glibc alone adds 1.5MB to the memory usage of every process. But Win folks may not realize how significant this is. Most Windows applications ship with their own copies of almost all shared libraries used, which means that there is a huge amount of wasted memory under Windows that *actually affects you*. Under Linux, instead of shipping shared libraries with applications, folks have built tools to automatically download the latest shared libraries and use those across multiple applications. Result -- only one copy of the library need be in memory at a time. This means that it's actually reasonable to run a box with 128MB of memory and three remote users using the thing. You simply can't pull that under Windows and expect usability.
* This may not sound significant, but Linux's VM is (anecdotal evidence, of course) really solid. When I run out of memory under Windows, performance rapidly degrades -- bring an application to the foreground, and the system just starts churning. Under Linux, you can push a ways into VM and things generally keep functioning pretty well (this is one of the causes of people talking about "applications loading faster under WINE than Windows" when they're trying to prove that WINE is 'faster' than Windows -- good disk I/O and VM code).
Any program relying on (nontrivial) preemptive multithreading will be buggy.
What gets me is how some distro builders see a security warning about setuid/setgid binaries using lazy so loading, and decide that using -Wl,-z,now is a good thing to add. Excuse me, but that will pull in EVERY library at link time, whether used or not, often leading to some MAJOR bloat.
Yes, it "fixes" the "problem", but so would using rpath to DSOs not writable by users or ensuring that LD_LIBRARY_PATH doesn't point to user writable directories. Without the load time bloat.
Regards,
--
*Art
In the days when I was first involved in setting-up Unix systems (when SUN 3s were the fancy new toy), 8MB was a huge deal on a system with 4MB RAM. Thus we essentially banned emacs and stuck to vi. Now my thought would be "only 8MB, whats the worry".
... and not only from Microsoft.
But has emacs also had feature creep since then, with corresponding memory growth?
Worrying too much about effeciency (memory or processor) can be bad. Failing to keep it at least in the back of your mind while designing and coding leads to some of the awful performance we see in some programs nowadays
.. and I thought that Apple passed the code to do this back to Sun over a year ago.
When you can remember running 60 users on a mainframe with about 1MB RAM and a processor no faster than a 386.
For real fun with Firefox, download a RELEASE COPY of the source code. I want to stress this - not a beta, not a nightly, grab an actual release copy. Compile it with debugging enabled, and run it.
Then start counting assertion errors in the RELEASE COPY of Firefox. It can be a fun drinking game, for every assertion error, drink.
It makes you wonder how Firefox 1.5 was ever released, since merely STARTING the damned thing causes like three assertion errors before the first window is even displayed.
I'm running OS X 10.4.4 and I know for sure that in the past there has been a utility similar to "pmap" that was called vmmap.
/usr/bin/vmmap
The path was
But it's somehow disappeared from OS X. Anybody know why?
Not only that, but Konqueror and Opera are often described as feeling far more responsive, while being extremely stable.
Actually, I would really prefer to use Konqueror (I use KDE and I really like the integration), but I use Firefox because Konq is so much slower. I just tested it again and Konq is *much* slower on my system. I picked a site that I hadn't visited for months (to make sure Firefox didn't have a cache advantage), typed the URL into each browser, clicked on Konq and hit enter, then clicked on Firefox and hit enter -- the result was that Firefox had the full page displayed nine *seconds* before Konqueror did, in spite of Konq's half-second headstart.
Thinking that maybe Firefox had an advantage because it was loaded and had been in use for a while, I (laboriously) browsed around a bit with Konq and then tried the same test again with another rarely-visited site. Same result.
Konq wasn't always slow, either. Back in the KDE 3.0 days, it was my primary browser, but during some update it just got terribly slow, so I switched to FF.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
About 8 months back I attempted to embed Gecko within an existing graphical user interface toolkit. Having heard so much from the open source community about how easy it was to do, I thought it would go rather quickly. Of course, it did not.
I'm not sure why you struggled, but I had no trouble embedding Gecko in a wxWidgets application - it took me a couple of hours at most.
My c0d1ng sk1llz are not 1337, but I do know why there are such a thing as shared libraries. They seem to bring problems though. They are failure sources as you cannot ascertain that every recipient of a software package has the required library installed. In fact, my failure rate in compiling bleeding-edge Linux software is staggering. I can count a few successes and a metric shitload of failures due to missing libraries. Talk about DLL hell! And as it seems, libraries are filled to the brim with features that are certainly not used at every given time. Thus, what is the point with loading the whole nine yards if all you need is a simple function? Need one JOptionPane? Import the whole freaking javax.swing.*; ! Wouldn't it be reasonable to be able to statically link to [i]only the feature you are using[/i]? To only "check out" that piece of the library as you compile? Perhaps this is already a well-known capability of coding languages, but I haven't heard of it.
Please mod parent up, and also parent of parent deserves even more positive mods. I finally understood what it is going on and why is it so difficult to show the *real* numbers because the heavy memory optimization that it is going on. Impressive.
As for the embedding of Gecko, I said to hell with it. I took a page from Apple, and used KHTML instead. The loss in portability by not going with Gecko was well worth the far quicker development time, the lower memory consumption, the increased responsiveness, and the higher degree of stability of KHTML.
What exactly is the portability problem with KHTML? I would be interested in a KHTML browser for windows and it's been said that with Qt4 and the work of various developers you'll be able to get an almost complete KDE 4 environment in windows.
http://www.teamquest.com/resources/gunther/ldavg1. shtml
I didn't think the house band in Hell would play this badly.
I just wanted to add my confirmation that the Apache article is an excellent tip.
I had been experiencing issues reaching the max clients on a busy apache server serving around 6mbit/sec of images at peak times, and had been forced to increase the maximum child process setting to a very large number to cope with the peak daily periods.
Having just made the changes recommended in that article, ie. changing the keep alive timeout to around 2 seconds rather than the default of 15 - we've gone from an average of 100+ child processes to a constant of 20-30.
I'd advise anyone experiencing problems hitting their max client setting (the example he gives is a slashdotting, in my case it's serving loads of individual images) to try this setting out.
That is how it should be read I think. To start 200 instances of your Java proggie you pretty much did the same thing as starting 200 threads in single virtual machine. These threads show in ps output as operating system processes and they map entire address space of virtual machine which is why their sizes are identical.
Memory usage of Java actually scales very nicely with silly number of threads. A couple of months ago I created a small server which opened lots of listener sockets in their own threads.
With one thread the size of the virtual machine about 40 megs which pretty much for a simple application but when I created more server threads the amount of added memory was very small. With 100 listener threads it was like 60 megs, with 400 it was 80 megs and finally with 3000 server threads the amount of used memory was only 290megs!
It is true that these threads were not actually doing anyting except listening on their sockets but I thing it is very impressive nevertheless.
So, great, you can split out the pages associated with a lib versus allocated directly. But this still doesn't show you how much memory the program is actually using. My bittorent client is actually using 55 megs of ram, but pmap will show 161 megs of writable/private.
Why? Because some is swapped out, and some is allocated but not used. Sure, swapped out is a cost, but in most apps things may get swapped out and never used again, thus the real cost of that memory usage is quite low.
Additionally the library cost is not to be dismissed. On my system I have many libraries loaded for just one process.
-josh
(shameless plug)
To help address the underlying problem which the blog points out I've written a tool called Exmap.
It uses a loadable kernel module to work out which pages are really shared between which processes, to provide some accurate numbers on memory usage in the face of complications such as demand-paging and copy-on-write.
It isn't intended to analyse the memory usage of a specific process so much as a system of processes using shared libs/mmap'd files. In particular it doesn't do any heap analysis (for that you probably want valgrind/massif or memprof).
But if you've got many processes running which use shared libs, this can help you work out your "real" memory usage. It'll also help you look at the usage of individual ELF sections and (if you're running non-stripped binaries) symbols.
It currently has some rough edges (e.g. no 64-bit support, some problems on pre-linked systems), sorry about that.
I've always thought that a much more useful data would be a report of which physical (and swap) page belongs to which process (or file / shared library).
Does anyone know of a tool that would do this (and do it accurately)?
Average Joe is already used to crashing apps and just accepts it as a part of life. Stability will not impress Average Joe
Stability may not, but recoverability sure as hell does. Although it's pretty hard to reliably crash Opera, when the "Joe Users" who've seen Opera crash on me then see it start right back up with everything just as it was previously, they are impressed beyond belief.
I try explaining to them that they could do the same thing with Firefox, but they have to install and configure an extension; for some reason, they are nowhere near as impressed with that idea.
http://primates.ximian.com/~federico/news-2005-11. html#moz-imagesFederico Mena-Quintero firefox memory useage analysis
" When you run Mozilla or Firefox and load a web page with images, it stores the uncompressed images as pixmaps in the X server. In particular, it seems to maintain live pixmaps for all the images in all the tabs that you have open; even if a tab is not visible, the images will be in your X server's memory."
It's worthwhile, as an exercise, to build an application with all libraries statically linked. That gives you a real size number to compare against. If that number is much smaller than the size with shared libraries, linking with shared libraries may be a lose. Remember that if you run two instances of the same application, you share the code, so shared libraries are a win only when you have different apps sharing the same library.
This is also a load time issue. Bringing in a huge number of shared libraries is one of the things that runs up program launch times.
I guess you have used wxMozilla.
I wonder If you find embedding Gecko a little unstable... for example, browsing to Google's personal homepage (http://www.google.com/ig) just make the application (with Gecko embedded) crash.
Not to mention that you need to run your application inside a mozilla base installation directory.
So, yes it's easy to embed Gecko, but is it practical?
guinux
P.S.: This discussion has get way far from the original post =)
The average user probably does not care about how much memory is being consumed, in terms of a numerical value. But when they're told by their Linux-using friend that Firefox is a superior browser to Internet Explorer, and then find their system performance dropping after switching to Firefox, they won't be impressed.
And stability sure will impress the average user. I recall many regular users who were very surprised by the massive stability increase between Windows 98 and Windows 2000 or XP, for instance. It wasn't such a big deal for those of us who were already aware of NT, but the average user of Windows 98 or ME sure did notice the stability improvements offered by XP.
Cyric Zndovzny at your service.
There really isn't any problem besides KHTML depending on the KDE libraries, which as of the KDE 3.x releases aren't easily ported to Windows.
Indeed, once KDE 4 is released it shouldn't be a problem. But KDE 4 is still under heavy development at this time. I've heard estimates that it will be at least another year before things start to really stabilize with the development of KDE 4.
Cyric Zndovzny at your service.
Speaking of Linux memory usage...
My FC4 test box started thrashing Jan 27.
top managed only one screen of data which showed the load at 61. It took 30 minutes, but the poweroff command was finally accepted. It reported changing the run level to 0. Only output since then has been from the oom-killer reporting mostly crond processes and free swap which has gradually dropped from 660000kB to 460000kB.
Does this shared libraries phenomenon apply to XP as well? Am I suffering a major performance penalty by running Firefox and OpenOffice instead of utilized the shared libraries between XP, Word, and IE?
That's just not true, as someone else has swillden points out in this comment to the current story. Nobody should follow your suggestion.
Based on your over-simplified claim (which I'll call "wrong") the 43 java threads on my Tomcat box are using 3.0GB of RAM total, minus 426MB shared, which is impossible on a box with 256MB of RAM and 512MB swap.
More generally, the problem with ps (and top) is that they fail to highlight the most important piece of information: the amount of unshared memory each process is using, or, as TFA calls it, the "marginal cost" of each process.
Instead, they give you the total memory available to each process. That number is irrelevant to a user of that process. It won't tell you, for example, how much memory you'd save if you killed off any given process. It won't even tell you how much total memory (shared+unshared) that process is using... as others have pointed out, ps's number includes unused copy-on-write device-mapped memory.
ps is at best deceptive, if not actually wrong.
When I moderate, I only use "-1, Overrated". That way, I never get meta-moderated!
Funnily enough I didn't use wxMozilla, as I had some problems getting that to work or I think to compile - I can't remember exactly why as it was quite long ago, but I vaguely recall it had something to do with (lack of) Unicode support at the time, and I needed to build in Unicode mode. I decided to rather use wxActiveX and wxIE and use the ActiveX Gecko wrapper that emulates the IE API, so that I would have the option of easily choosing between IE and Gecko if one or the other gave too many problems (as the app was a Windows-only app I could do this). Both IE and Gecko were basically 'equally easy' to embed using this strategy - basically just one line of code change and a recompile to switch between the two. The actual process of embedding was also quite easy. But I found both though to be quite buggy or problematic --- just in different ways. The IE component is extremely buggy indeed and I've spent probably two weeks in total now just finding workarounds for the various bugs and "annoying retarded behaviour" aspects of it (and some of the workarounds created new problems). But the Gecko component had problems too --- particularly using in-memory streams was not properly supported and I needed that. (At least I thought I needed that, but ironically I ended up not using them anyway and having to find a crappy workaround because as it turned out IE also has other (different and random) problems with in-memory streams .. *sigh*.) But at the time, on weighing the pros/cons of each I ended up choosing to go with IE. The whole 'having to have that mozilla base directory installed' was definitely a factor, that sucks.
Embedding browser components was certainly a more horrible experience than I felt it should be. (But seemingly this is not unique to Gecko. Embedding IE is one of the most painful and annoying programming experiences I've ever had.)
I don't recall having any stability problems with Gecko, or having any crashes when using it or anything like that.
P.S.: This discussion has get way far from the original post =)
Yup :)
No, no, no, they are not memory leaks, they are analyzing for the preventing of memory leaks!!!
What??!!
Yes, there are using a page per character.
Is it bad for you?
Maybe the way to deal with shared memory is to just apportion it to applications. If there are 5 applications sharing 100M then each gets 20M. That way, we can get a better idea of how much impact each individual application has, assuming everything else remains the same.
So true, so true.
Now, there's not even a guarantee that your mmap()'d memory has backing store behind it.
For a quick result the Activity Monitor has the option under the View --> Columns menu to show not just the usual Real Memory and Virtual Memory, but also Private Memory and Shared.
Stability might not impress Average Joe, but when Firefox crashes every 20 minutes (Firefox 1.5, i'm looking at you), he will be even less impressed. I can't recall IE/XP Crashing more than a handful of times. I've never seen Opera crash. Firefox crashes like a demolition derby.
Do you even lift?
These aren't the 'roids you're looking for.
I'm almost positive that Linux does not use aforementioned method of relative addressing, as the only way to do that is using segmentation.
You have tried to support your argument with faulty reasoning! Go directly to jail; do not pass Go, do not collect $200!
Unless, of course, you use them on a regular basis. Opera crashes all the time, and still Konqueror suffers from all sorts of wierd slowdowns and crashes.
According to the help message, this is because you asked for:
That's, uh, a strange user name you have there. If I drop off the "-" to use BSD syntax, it seems to fail on the "i" option.
mime is money.
As a side note, it should be said that KHTML is also available for GTK.
My worst enemy gave me a copy of Windows for Christmas.