OSNews

Simply talking about 'memory fragmentation' is dumb. Memory has constant access time, it doesn't matter how distributed accross the system it is.

Have a look at this http://ub0.cc/41/p

He's not talking about Windows memory defragmentation, he's talking about the browsers' internal memory allocation process that allocates virtual space to the browser. This article demonstrates memory fragmentation clearly http://blog.pavlov.net/2007/11/10/memory-fragmentation/ and it does have a significant effect on the browser.

Your statement that memory has constant access time demonstrates your clear lack of comprehension of why computers have many levels of memory from the CPU register (fastest) to L1 cache (still very fast) to L2 cache (fast) to perhaps L3 (not too shabby if you're not too concerned) to main RAM (lots of latencies for grabbing anything not currently in the previously mentioned levels of the hierarchy) to finally, paged RAM from a swap file (painfully slow) to offline storage (get out the hamsters!). They all have their place, as a result of the fact that higher speed=more money in a non-linear fashion for the speed.

Main RAM access is often these days at least a factor slower than on-CPU access, and swapped memory from a disk of ANY type is many orders of magnitude slower than that: once you've used enough RAM that hits the VM such that things start getting swapped out, everything can start operating much slower. Memory leaks often result in greater allocation usage that then brings on the need for swapping, but it is entirely possible (and I've seen applications purposely coded this way, though it's not the way I do things) where the memory is allocated contiguously as far as total application memory goes, and nothing is ever freed: this solves the problem of internal memory fragmentation, sure, but it merely pushes the problem to a system level rather than only (if that's possible: often not, if an application ever exceeds a fixed memory usage set at startup of the application, which most applications that aren't embedded simply don't do) the application level.

And then you have what's known as memory fragmentation, which is far worse than disk fragmentation: in a filesystem, it's no big deal management-wise if you have a file that gets fragmented, at least with most filesystems (ISO9660 being one where it isn't allowed, but then, it isn't a dynamically changing filesystem anyway, and is read-only after writing originally) since in most of them, chunks of the file are handled at the lowest level in increments of blocks of bytes, usually powers of 2, and in many done by extents of blocks that are stored this way, and these are all tracked, and files can be strewn amongst many of these and the OS makes it appear all contiguous from the point of view of all applications. Well, this just doesn't happen in standard applications when they have memory fragmentation: what happens is that n bytes are allocated, n+m bytes are allocated, another m bytes are allocated, and then sooner or later the n+m bytes are released, leaving an n+m block free, but what if there isn't something that exactly fits in that memory? That's fragmentation: if it doesn't fit exactly there, if the new memory allocation request is smaller, it might reused part of that block of n+m bytes, still leaving a small chunk that may be too small for some other useful allocation later, but if it is bigger, it must then find a chunk elsewhere in the application heap to allocate a new chunk that's big enough, and forget about even using part of that memory for that new allocation: it's not common for applications to work like a filesystem and link things together, and it'd be slow besides, for most cases, because of the previously mentioned levels of memory hierarchy. Of course, what happens over time (and web browsers are a prime example of extremes in memory allocations, with short strings of text using a few bytes to megs used per picture) is that there's then all these small odd bits of unused memory between all the currently used chunks: the total amount of unused RAM may be >50% of total RAM used (granted, I'm just pulling a number out of a nether region) and to the uninformed user that doesn't have a debugger and the code, that looks suspiciously like a memory leak. Of course, if there truly is a memory leak involved, that just compounds the error. What happens once the memory usage exceeds a certain amount? Why, of course: our favorite memory hierarchy starts playing a very important part where the non-constant access time matters: more RAM is allocated for that application's heap, but that comes out of the VM and filesystem cache pool (depending on the OS) and... that can cause things to be swapped out, including memory used by that current application. Thus, things are no longer so linear, and actually can become unpredictably exponential, with all the overall application and system interactions.

It seems from the article that the writer has just enough background in theory to be dangerous: being able to recite some basic theory and the implications, without actually knowing how it all fits together in practice. This is a common oversight of many CS people that have no practical experience, and especially those that have not studied the actual hardware and understood its limitations in executing theoretical concepts in a real world practical space.