Is there an easy way to determine the working set size (resident size) that is needed to evaluate some form? TIME prints various things but not what I need. The Linux top command shows a column with the resident size; essentially I'd like to see the maximum of the those values sampled while executing the form. Does the GC have this information already? Would it be difficult/expensive to use getrusage in GC hooks to collect the information? Helmut
Is there an easy way to determine the working set size (resident size) that is needed to evaluate some form?
TIME prints various things but not what I need. The Linux top command shows a column with the resident size; essentially I'd like to see the maximum of the those values sampled while executing the form.
Does the GC have this information already? Would it be difficult/expensive to use getrusage in GC hooks to collect the information? I don't see why you can't use getrusage in a GC hook to get his information. After all, you made slime use a GC hook to show how much memory is used in each generation when a GC happens. Would summing up
On 11/5/10 3:41 PM, Helmut Eller wrote: the memory usage in each generation be close enough to the resident size that you want? I ran unix-getrusage on several systems I have access to. They all seem to return 0 for the maxrss value, so that might not be useful to you. Ray
* Raymond Toy [2010-11-06 11:58] writes:
Is there an easy way to determine the working set size (resident size) that is needed to evaluate some form?
TIME prints various things but not what I need. The Linux top command shows a column with the resident size; essentially I'd like to see the maximum of the those values sampled while executing the form.
Does the GC have this information already? Would it be difficult/expensive to use getrusage in GC hooks to collect the information? I don't see why you can't use getrusage in a GC hook to get his information. After all, you made slime use a GC hook to show how much memory is used in each generation when a GC happens. Would summing up
On 11/5/10 3:41 PM, Helmut Eller wrote: the memory usage in each generation be close enough to the resident size that you want?
Would that include the space needed to run the GC? Doesn't the GC need about twice us much while moving from-space to to-space? Helmut
On 11/6/10 8:29 AM, Helmut Eller wrote:
* Raymond Toy [2010-11-06 11:58] writes:
Is there an easy way to determine the working set size (resident size) that is needed to evaluate some form?
TIME prints various things but not what I need. The Linux top command shows a column with the resident size; essentially I'd like to see the maximum of the those values sampled while executing the form.
Does the GC have this information already? Would it be difficult/expensive to use getrusage in GC hooks to collect the information? I don't see why you can't use getrusage in a GC hook to get his information. After all, you made slime use a GC hook to show how much memory is used in each generation when a GC happens. Would summing up
On 11/5/10 3:41 PM, Helmut Eller wrote: the memory usage in each generation be close enough to the resident size that you want? Would that include the space needed to run the GC? Doesn't the GC need about twice us much while moving from-space to to-space? No, I don't think the space needed to run the GC is included. Since it's a copying GC, I think the extra space needed is equal to the space retained; the stuff that is not copied is garbage.
The *gc-notify-after* hook is given the bytes retained and the bytes freed. I guess the bytes retained would be the extra space needed for GCing. I don't think this includes the space needed by the static space, or the read-only space. Note that there is a space profiler too that Martin contributed many years ago. (See profile::with-space-reports.) I've never actually used this before. Ray
participants (2)
-
Helmut Eller -
Raymond Toy