Issue530

Title M&S refactoring: replace estimated with actual memory usage
Priority wish Status resolved
Superseder Nosy List malte, silvan
Assigned To silvan Keywords
Optional summary

Created on 2015-05-13.11:19:45 by silvan, last changed by silvan.

Messages
msg4207 (view) Author: silvan Date: 2015-05-18.16:24:45
(This was part of meta issue432.)
msg4205 (view) Author: silvan Date: 2015-05-13.16:42:01
Resolved.
msg4204 (view) Author: malte Date: 2015-05-13.16:35:00
Feel free to close.
msg4203 (view) Author: silvan Date: 2015-05-13.16:34:24
Done. Unless there is anything else to do, this can be closed already.
msg4202 (view) Author: malte Date: 2015-05-13.16:00:04
Works for me. It would perhaps be nice if it could be easy to add it to other
places for debugging (e.g. if it's a simple function call
"report_peak_memory_delta" that could in principle be called from many places).
msg4201 (view) Author: silvan Date: 2015-05-13.15:38:13
I implemented the delta output. There is only one drawback of taking out the
estimated memory usage of transition systems that I can see: we do not have any
memory statistics of single transition systems anymore. On the other hand, what
matters is the total memory usage of all transition systems (and everything else
related to merge-and-shrink), so I think this is fine.

Do you think one output of peak memory delta per merge-and-shrink iteration is
fine? I put it after the merge step.
msg4197 (view) Author: malte Date: 2015-05-13.13:18:13
Yes, peak memory is the only thing that can actually be measured. We must be
aware that there are many things that can make this inaccurate (memory
fragmentation, memory sometimes being requested from the OS in chunks of 1 MB or
more, memory that has already been allocated but not used), but at least we get
real data.
msg4196 (view) Author: silvan Date: 2015-05-13.11:19:45
We want to replace all the estimated memory stuff with actual memory 
measurements. Malte, you once suggested to compute the delta of memory usage
before and after (or during) the merge-and-shrink construction. Did you mean the
existing "peak memory" mechanism we have? This probably works because before
starting the merge-and-shrink computation, not a lot of memory should have been
allocated, right?
History
Date User Action Args
2015-05-18 16:24:45silvansetmessages: + msg4207
2015-05-13 16:42:01silvansetstatus: chatting -> resolved
messages: + msg4205
2015-05-13 16:35:00maltesetmessages: + msg4204
2015-05-13 16:34:24silvansetmessages: + msg4203
2015-05-13 16:00:04maltesetmessages: + msg4202
2015-05-13 15:38:13silvansetmessages: + msg4201
2015-05-13 13:18:13maltesetmessages: + msg4197
2015-05-13 11:19:45silvancreate