Any one ever try/use IFreeMem?
in [Mac Applications]
|
From: Clever Monkey on 15 Feb 2007 12:04 Tim Lance wrote: > On Thu, 15 Feb 2007 01:36:39 -0600, Paul Sture wrote > (in article <paul.sture.nospam-B4DBB2.08363815022007(a)mac.sture.homeip.net>): > >> In article <tph-0ABCE7.13113814022007(a)localhost>, >> Tom Harrington <tph(a)pcisys.no.spam.dammit.net> wrote: >> >>>> http://www.activata.co.uk/products/ifreemem.html >>> Sounds like a crock to me. >> Try http://www.activata.co.uk/products/ >> >> and explore a little... >> >>> -) >> > > OP here. I have been through that and have email from the developer. I > specifically asked for for a more detailed explanation of what was going on > and got some BS about how he wrote it for himself and uses it about 3 times a > day. > > Nevertheless I'm inclined to believe it's doing something good. I just don't > understand VM very much beyond the basic idea of it. The folks here that I > believe do know more seem inclined to discount it but have not seen it in > action. > > In my laymen way this is what I think is going on. Even though OS X memory > management is light years more efficient than previous, it still is not as > good as it might be. Yes, when you start an app only so much is gobbled up. > But I'm wondering that, as time goes by, some of that which is allotted and > used may not be needed anymore but is still sitting around in a real state > and not in VM. Is this app able to look at such and put it into VM thus > freeing up real? Is that the effect? Is that why having 7 swap files normally > would slow my machine but with them being made this way, all is fine. That > is, this VM is "doing nothing" memory, memory not being called - inert, if > you will. These swap files are then not much more than any other file sitting > on the drive not being used - space being the only issue, not performance. > The graphic depiction of dramatic increases of free memory are real (verified > by MemoryStick and Activity Monitor). The performance improvement *feels* > real - real enough that I'll continue to trial this and try to do as valid as > possible compare and contrast tests. > This is not really how VM managers work. The idea is to have a pool of memory, shared, real and virtual, this is managed as a resource for userland processes. The kernel keeps some of that memory for itself, and doles out the rest. This app my be forcing some sort of free block collection and compaction, which is essentially flushing dirty blocks and collecting stale blocks. This is normally something that is normally done as a low-priority process that can be preempted. This is not only unnecessary, but may actually force the VM to work harder than it really needs to. CPU, memory and disk space are resources that are managed closely by the kernel and doled out on an as-needed basis. Many operations that are not critical to providing those resources are "lazy" on purpose. It simply does not matter if deallocated memory is not always promptly flushed or compacted (or whatever the OS X model of VM does when managing this resource). Without a clear explanation of what this app is doing, or published source, my feelings are that this is 100% snake-oil.
From: Clever Monkey on 15 Feb 2007 12:06 Tim Lance wrote: > On Wed, 14 Feb 2007 16:51:55 -0600, Tom Harrington wrote > (in article <tph-3EFB76.15515414022007(a)localhost>): > >> In article <f6qdnZB5z4TKFk7YnZ2dnUVZ_uXinZ2d(a)giganews.com>, >> Tim Lance <see.sig(a)bottom.com> wrote: >> >>> And this from the last "Optimize Memory" run (taking it to 7 swap files but >>> getting me back to almost a GB free memory. Even I can see that's a bunch >>> of >>> pageouts - just not sure what it means. >> What are you trying to accomplish here? What symptom or problem are you >> hoping to fix? >> >> > Oh, merely to free up memory if it can be done. but more I'm just curious > about how it all works. > The memory will be freed up as the VM find it necessary. If that memory was really needed, it would have been freed already. If the VM starts to thrash trying to free up resources that it cannot, no amount of forcing it to thrash further will fix anything.
From: Tom Harrington on 15 Feb 2007 15:00 In article <lsWdnTkdAa3z1UnYnZ2dnUVZ_tadnZ2d(a)giganews.com>, Tim Lance <see.sig(a)bottom.com> wrote: > OP here. I have been through that and have email from the developer. I > specifically asked for for a more detailed explanation of what was going on > and got some BS about how he wrote it for himself and uses it about 3 times a > day. > > Nevertheless I'm inclined to believe it's doing something good. I just don't > understand VM very much beyond the basic idea of it. The folks here that I > believe do know more seem inclined to discount it but have not seen it in > action. > > In my laymen way this is what I think is going on. Even though OS X memory > management is light years more efficient than previous, it still is not as > good as it might be. Yes, when you start an app only so much is gobbled up. > But I'm wondering that, as time goes by, some of that which is allotted and > used may not be needed anymore but is still sitting around in a real state > and not in VM. Is this app able to look at such and put it into VM thus > freeing up real? Is that the effect? That's not a meaningful statement. All memory is virtual on Mac OS X, so moving something from "real" memory into virtual memory is not something that even makes sense. Both RAM and swap files are part of the virtual memory system. I'm guessing here that when you refer to VM you're actually thinking of the swap files on disk. In that case, the answer is "no". The whole idea of Unix virtual memory is that an application does not and cannot know if the memory it has is in RAM or has been swapped to disk, and therefore it cannot exert any control over swapping. Application developers have no need to move data between swap files and RAM-- the operating system handles this transparently as needed. In some high-performance applications it's possible to tell the OS never to let a block of memory be swapped to disk, but this is pretty unusual and not something likely to be happening in any application you're running. Getting back to the subject at hand, though-- "Inactive" memory is almost but not quite the same as "free". If an application needs memory and there's not enough "free", then the operating system will grab from inactive and hand it over. However-- in some cases the data in the inactive memory will need to be written to disk first, so it might take a little longer than if the memory was in the "free" group. There are various hacks one can use to force the operating system to clear this stuff out of the inactive pool. It sounds like this might be what iFreeMem is doing. Even allowing this, I stand by the idea that doing so is a crock. The reason is-- you may force the OS to write data from inactive memory to disk, and memory allocations may be a little faster afterward. But sooner or later the OS is going to want to read that data back from disk into RAM. In other words, doing this may give you a temporary improvement in performance, but you'll pay for it later. Having the graph show a drop in inactive memory and a corresponding rise in free looks nice but doesn't ultimately benefit you. That's only addressing what iFreeMem is potentially doing with regard to inactive memory. I'm reading a lot into the description because the description is so vague. In other parts of the web page there's talk of making your Mac run like it was new as a result of using the application. This, and I cannot emphasize this enough, is complete and utter bullshit. Every time your Mac reboots, all memory of all kinds is completely cleared out, and you start with a blank page. Memory performance and availability does not decline as your Mac gets older, so the idea that iFreeMem is somehow reversing some kind of gradual decline is nonsense. -- Tom "Tom" Harrington MondoMouse makes your mouse mightier See http://www.atomicbird.com/mondomouse/
From: Clever Monkey on 15 Feb 2007 16:28 Tim Lance wrote: > On Thu, 15 Feb 2007 11:04:53 -0600, Clever Monkey wrote > (in article <Vo0Bh.51138$43.38061(a)nnrp.ca.mci.com!nnrp1.uunet.ca>): > >> Tim Lance wrote: >>> On Thu, 15 Feb 2007 01:36:39 -0600, Paul Sture wrote >>> (in article <paul.sture.nospam-B4DBB2.08363815022007(a)mac.sture.homeip.net>): >>> >>>> In article <tph-0ABCE7.13113814022007(a)localhost>, >>>> Tom Harrington <tph(a)pcisys.no.spam.dammit.net> wrote: >>>> >>>>>> http://www.activata.co.uk/products/ifreemem.html >>>>> Sounds like a crock to me. >>>> Try http://www.activata.co.uk/products/ >>>> >>>> and explore a little... >>>> >>>>> -) >>> OP here. I have been through that and have email from the developer. I >>> specifically asked for for a more detailed explanation of what was going on >>> and got some BS about how he wrote it for himself and uses it about 3 times >>> a >>> day. >>> >>> Nevertheless I'm inclined to believe it's doing something good. I just >>> don't >>> understand VM very much beyond the basic idea of it. The folks here that I >>> believe do know more seem inclined to discount it but have not seen it in >>> action. >>> >>> In my laymen way this is what I think is going on. Even though OS X memory >>> management is light years more efficient than previous, it still is not as >>> good as it might be. Yes, when you start an app only so much is gobbled up. >>> But I'm wondering that, as time goes by, some of that which is allotted and >>> used may not be needed anymore but is still sitting around in a real state >>> and not in VM. Is this app able to look at such and put it into VM thus >>> freeing up real? Is that the effect? Is that why having 7 swap files >>> normally >>> would slow my machine but with them being made this way, all is fine. That >>> is, this VM is "doing nothing" memory, memory not being called - inert, if >>> you will. These swap files are then not much more than any other file >>> sitting >>> on the drive not being used - space being the only issue, not performance. >>> The graphic depiction of dramatic increases of free memory are real >>> (verified >>> by MemoryStick and Activity Monitor). The performance improvement *feels* >>> real - real enough that I'll continue to trial this and try to do as valid >>> as >>> possible compare and contrast tests. >>> >> This is not really how VM managers work. The idea is to have a pool of >> memory, shared, real and virtual, this is managed as a resource for >> userland processes. The kernel keeps some of that memory for itself, >> and doles out the rest. >> >> This app my be forcing some sort of free block collection and >> compaction, which is essentially flushing dirty blocks and collecting >> stale blocks. This is normally something that is normally done as a >> low-priority process that can be preempted. >> >> This is not only unnecessary, but may actually force the VM to work >> harder than it really needs to. >> >> CPU, memory and disk space are resources that are managed closely by the >> kernel and doled out on an as-needed basis. Many operations that are >> not critical to providing those resources are "lazy" on purpose. It >> simply does not matter if deallocated memory is not always promptly >> flushed or compacted (or whatever the OS X model of VM does when >> managing this resource). >> >> Without a clear explanation of what this app is doing, or published >> source, my feelings are that this is 100% snake-oil. > > Thank you for this. I get most of it - well, all, as far as it goes. Just > don't ask me to explain it yet again to someone else. > > Along those lines, may I quote some of this to the developer when I write him > later? > I was hand-waving and generalizing. I have not looked at the Next or OS X VM stuff in my life, but I think about this stuff for a living on other platforms. VM systems are pretty similar from the same height, but the devil is in the details. However, my comments about the developer specifying _exactly_ what this user-land process is doing to affect kernel-land stuff still stand.
From: VAXman- on 15 Feb 2007 16:37
In article <tph-7DCF13.13002715022007(a)localhost>, Tom Harrington <tph(a)pcisys.no.spam.dammit.net> writes: > > >In article <lsWdnTkdAa3z1UnYnZ2dnUVZ_tadnZ2d(a)giganews.com>, > Tim Lance <see.sig(a)bottom.com> wrote: > >> OP here. I have been through that and have email from the developer. I >> specifically asked for for a more detailed explanation of what was going on >> and got some BS about how he wrote it for himself and uses it about 3 times a >> day. >> >> Nevertheless I'm inclined to believe it's doing something good. I just don't >> understand VM very much beyond the basic idea of it. The folks here that I >> believe do know more seem inclined to discount it but have not seen it in >> action. >> >> In my laymen way this is what I think is going on. Even though OS X memory >> management is light years more efficient than previous, it still is not as >> good as it might be. Yes, when you start an app only so much is gobbled up. >> But I'm wondering that, as time goes by, some of that which is allotted and >> used may not be needed anymore but is still sitting around in a real state >> and not in VM. Is this app able to look at such and put it into VM thus >> freeing up real? Is that the effect? > >That's not a meaningful statement. All memory is virtual on Mac OS X, >so moving something from "real" memory into virtual memory is not >something that even makes sense. Both RAM and swap files are part of >the virtual memory system. Thank you, you beat me to it. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" |