<div class="gmail_quote">On Sat, Sep 17, 2011 at 01:07, Shri <span dir="ltr"><<a href="mailto:abhyshr@mcs.anl.gov">abhyshr@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> That space is allocated, but the matrix has been compacted so only the<br>
> first<br>
> 832 slots in the array are considered. The other part gets pushed out<br>
> to<br>
> slow memory and only takes up space, not bandwidth. This is often not<br>
> a big<br>
> deal.<br>
<br>
</div>What is the reason for retaining this 'extra' memory? Is it to avoid fetching memory again<br>
if the user wants to insert more values in the matrix via any future assembly calls?</blockquote></div><br><div>Reallocating, copying, and freeing may increase the peak memory usage of the application, thus limiting the problem size. In practice, on most systems with virtual memory, the extra memory could be released using realloc() without needing a copy. On an offset-mapped system (e.g. BG/P), this could cause fairly serious fragmentation problems, so the operating system might prefer to copy.</div>
<div><br></div><div>I don't know why PETSc has never adopted the use of realloc(). I suspect that portability is a problem, but could improve performance a bit for some dynamically growing data structures, and in some common cases like matrix preallocation, allow some space to be recovered.</div>