Any one ever try/use IFreeMem?
in [Mac Applications]
|
From: John W on 15 Feb 2007 19:44 Guys, Hello, I am the developer, my ears were burning :) Firstly apologies if my attempt at non tech marketing talk on the website is not to your liking, I'm soon to be working on providing a tech head breakdown/FAQ/Help of what is it doing for those that want to dig deeper, not had time as yet. I do however stand by the product, and use it myself regularly. It certainly does improve things on my machines. v1.0 was released only 2 days ago so I am interested in any problems people have with the trial so I can fix them. The problem I was trying to solve by writing the software was that my machine becomes low on Free memory, the machine become unresponsive and there is lots of disk activity. A lot of cached memory is kept around even if all apps are closed down, solution was to reboot. Also I usually get a new Mac every few months and performance is better at the beginning when Mac is new. I wanted to prevent the just-in-time clean-up that occurs when I am in the middle of doing some work, I personally find this frustrating. The aim was to have the memory footprint of a new mac, that is uncluttered with cached items, on demand. Did it solve my problem? Yes it does! Do I use it regularly? absolutely Would I have released it if it did not, no chance! Is the net result of running the app just like the description of what its says on the website? Is for me. Does it work for you?, I don't know, maybe you don't notice the system stalls or spinning ball when free memory becomes scarce, its been an issue for me. I am personally very happy with the product, the direct feedback I get is also positive. With respect, there are a few expert opinions floating here, but there is also a 15 day trial, I think the only fair way of knowing is to try it and see if it works for you, or not. On 15/2/07 21:28, in article ug4Bh.51164$43.33806(a)nnrp.ca.mci.com!nnrp1.uunet.ca, "Clever Monkey" <clvrmnky.invalid(a)hotmail.com.invalid> wrote: > 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. -- ********************* Mac Developer Tools http://www.activata.co.uk *********************
From: Tom Harrington on 16 Feb 2007 00:25 In article <C1FAAF4B.9555%jon(a)no-reply.invalid>, John W <jon(a)no-reply.invalid> wrote: > Also I usually get a new Mac every few months and performance is better at > the beginning when Mac is new. I wanted to prevent the just-in-time clean-up > that occurs when I am in the middle of doing some work, I personally find > this frustrating. > > The aim was to have the memory footprint of a new mac, that is uncluttered > with cached items, on demand. I'd be most interested to hear your theories on how RAM becomes less useful as a Mac ages, and how your app manages to revitalize it. How does the memory of the RAM change over time? -- Tom "Tom" Harrington MondoMouse makes your mouse mightier See http://www.atomicbird.com/mondomouse/
From: John W on 16 Feb 2007 06:46 On 16/2/07 05:25, in article tph-CE1180.22251815022007(a)localhost, "Tom Harrington" <tph(a)pcisys.no.spam.dammit.net> wrote: > I'd be most interested to hear your theories on how RAM becomes less > useful as a Mac ages, and how your app manages to revitalize it. How > does the memory of the RAM change over time? Tom, What? "memory of the RAM", "RAM becomes less useful" where exactly are you plucking these statements, I did not say such things as they don't even make sense. John
From: Tom Stiller on 16 Feb 2007 07:08 In article <C1FB4A44.98C1%jon(a)no-reply.invalid>, John W <jon(a)no-reply.invalid> wrote: > On 16/2/07 05:25, in article tph-CE1180.22251815022007(a)localhost, "Tom > Harrington" <tph(a)pcisys.no.spam.dammit.net> wrote: > > > I'd be most interested to hear your theories on how RAM becomes less > > useful as a Mac ages, and how your app manages to revitalize it. How > > does the memory of the RAM change over time? > > Tom, > > What? > > "memory of the RAM", "RAM becomes less useful" where exactly are you > plucking these statements, I did not say such things as they don't even make > sense. But you _did_ say: > Also I usually get a new Mac every few months and performance is better at > the beginning when Mac is new. I wanted to prevent the just-in-time clean-up > that occurs when I am in the middle of doing some work, I personally find > this frustrating. > > The aim was to have the memory footprint of a new mac, that is uncluttered > with cached items, on demand. and we wonder just how the performance of the "memory" on a new Mac degrades over time, as you imply. -- Tom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF
From: John W on 16 Feb 2007 07:35
On 16/2/07 12:08, in article tomstiller-2FA60F.07080716022007(a)comcast.dca.giganews.com, "Tom Stiller" <tomstiller(a)comcast.net> wrote: >> >> What? >> >> "memory of the RAM", "RAM becomes less useful" where exactly are you >> plucking these statements, I did not say such things as they don't even make >> sense. > > But you _did_ say: >> Also I usually get a new Mac every few months and performance is better at >> the beginning when Mac is new. I wanted to prevent the just-in-time clean-up >> that occurs when I am in the middle of doing some work, I personally find >> this frustrating. >> >> The aim was to have the memory footprint of a new mac, that is uncluttered >> with cached items, on demand. > > and we wonder just how the performance of the "memory" on a new Mac > degrades over time, as you imply. > > -- > Tom Stiller -- Tom, Again, memory does not degrade, as that too does not make sense. I'm pretty sure many readers are able to conclude that's not what I have said, which is specific to a particular performance issue surrounding a particular cluttered memory condition that is less noticeable in a new mac. You seem to be implying that yours and everybody else mac run's just a sweet as the day they took it out the box, if that's the case for you great, nobody should ever need to worry about defragmentation, uninstalling apps, closing applications or reboot or re-install ever again, its all just run smoothly forever. |