One Feature request (release memory for specified processes) and a question

[watermelon]

The request would be a "release working set memory" for specific processes on schedule and/or if memory user is bigger than a) a set value for the process or b) bigger than a set relative value to the remaining free memory.

Option A would look like: Release memory if process X is using more than X MB
Option B: Release memory if process is using X% of all available memory X MB.
Time option: Release memory if A or B is true and time = X has passed.




My question is why the Other actions -> Trim virtual memory is not called "Trim working set memory" as this is what this feature is doing, or am I wrong?




And at last a suggestion: Hide the parts that do not apply for the system like setting affinity on single-core environments.




Thank you for having created Process Lasso. 

[Jeremy Collake]

Thanks for the feature requests. I'll see what I can do in future versions. What you want is covered by plans I have to create more advanced rules.

The reason I didn't use the term 'working set' is because I make half-hearted attempts to be understandable to the layman. My attempts end up being pretty pathetic, as I'm sure few non-geeks have any idea what most strings in Process Lasso mean ;o. Anyway, I think 'trim virtual memory' is accurate enough, and probably a little more likely to be understood than 'trim working set'.

Hiding affinity options for single-CPU systems is a good idea. I should implement it quickly, before all the single-CPU systems disappear . I may very well make that change soon.

Thanks for your support

[watermelon]

My bad, I shouldn't have suggested "working set" then if that term is not wanted but "physical memory" as opposed to the "virtual memory". That's not too hard for a layman, is it?

Btw, the working set size is already shown under running processes so a bit consistency wouldn't hurt either. Here the "virtual memory" also is called "commit size".. more confusion ahead.


Looking forward to playing around with the advanced rules you speak of. 

[Jeremy Collake]

Ah, yes, I misunderstood your message. I may change that string. Every string change is so much work anymore that I avoid changing them.. but I really shouldn't avoid changes like that. I need to care most about the English version and let the translators keep their languages up to date (or not). After all, English is the language used by 90%+ of customers -- with Japanese taking up most of the remaining 10%. Well, ok, those are wild guesses...

You're right the strings aren't consistent as-is. I noticed this a while back and actually had planned to change the memory column names to make them more understandable. But, I had deferred this, again, because of not wanting to break translations. Sigh.

Anyway, I'll see what I can do in my continued struggle to develop the best software I can. Lately, minor maintenance has slowed down the larger chores like major new feature additions, but that is the nature of software development. I must keep up with maintenance ;o

[horizon]

No offence(!!!), but I am pretty pesimistic about any 3rd party memory management attempts.

What is this feature good for?

Afaik Winnt have a very good memory management, thus if some app asks for memory (and it's physically available, it will get it) It should be as well be able to trim process if it has got allocated memory it does not really used. The process by default gets just a "promiss" of memory, but it's actualy not blocked and until really used, it's physically available for other processes.)

If the process really consumes unreasonable amount of memory. (Bad application design or some memory leak), there is nothing that can be done about that either by windows or by any trimming.

The best scenario for any 3rd party "memory management tools" is they are harmless. Or is this another case?

Regards
Lukas

[Jeremy Collake]

No offence(!!!), but I am pretty pesimistic about any 3rd party memory management attempts.

You and me both, to be honest. That is why on the periodic memory trimming feature I say 'not recommended'. Most software authors would just throw the feature in there and let people use it, but I wanted it to be clear even in the menus that I don't normally recommend it.

What is this feature good for?

In certain very specific situations, some users do need this feature. I've written articles on this topic before, and done a lot of analysis. This is going to be one of those features that I'll add, because people want it, then have my own warnings and recommendations not to use it carelessly.

The best scenario for any 3rd party "memory management tools" is they are harmless. Or is this another case?

One case where it is marginally useful is if you were about to launch a process that required a lot of new memory allocation, and your memory was already fully allocated. In this case, it would cause the new process to launch faster because you have already done the paging out that would be done as it loads. Of course, for pages that are referenced again, they must be paged back in.. therefore the load time improvement is negated a little by this. But, if the user had Word or something open in the background, then doing a pre-trim before loading the memory intensive app (like a Game) would improve its load time..and Word wouldn't need to swap back in most of its pages until you went to use it again.

BUT, I'm with you, I'm not a big fan of the whole idea.. I just add features users request, and hope my warnings are enough to discourage casual use. However, for some users, in some scenarios, trimming of the working set (paging out) is appropriate.

[watermelon]

It certainly isn't a feature one would use if they didn't have to. In my case it is a few programs that can suck up a lot of memory over time (also known as memory leaks). Because my computer isn't that up-to-date anymore, the only way to not have system responsiveness decrease - is to release some memory for THOSE processes periodically.

[Jeremy Collake]

And at last a suggestion: Hide the parts that do not apply for the system like setting affinity on single-core environments.

I just completed this chore. It will be in v3.61.3 beta.

[watermelon]

Wonderful. 

I have thought of another thing missing: If I'm not totally blind there is no way of totally disabling writing a log file. We got too many programs doing that already. With all options disabled leaving only the startup as an event, the function becomes obsolete.

[Jeremy Collake]

I have thought of another thing missing: If I'm not totally blind there is no way of totally disabling writing a log file. We got too many programs doing that already. With all options disabled leaving only the startup as an event, the function becomes obsolete.

Good point, I'll see what I can do .