<br>I think it's conceptually not right to have Get()/Restore() pairs to do caching, but provide that feature only in special cases. Shouldn't other places that needs temp work vectors have a similar facility? I think a better way of handling this would be to get rid of the special Get()/Restore() caching pairs, and rather make caching a feature of the object itself. I.e., VecCreate() might have a pool of allocated vector data structures + associated data storage arrays. VecDestroy() would not really destroy a Vec but return it to the pool. Unfortunately that doesn't mix too well with how the real setup of a vector is done later, after options and potentially command line options have been processed, so by the time you know what kind of vector you want, you've pretty much already filled the data structure. And it also requires some more memory management framework which would call upon caches to expire long-unused objects when memory is running low.<br>
<br>I think a more consistent user interface would be to just have DACreateVec(), and something like MatCreateVecs(), and then VecDestroy() the Vec when you're done, no matter where it came from. Whether it's cached or not is an implementation detail. Probably the first thing to figure out would be whether caching is making an actual difference in the real world, and if not, there's a pretty straight forward solution...<br>
<br>--Kai<br><br><br><br><br><div class="gmail_quote">On Fri, Aug 27, 2010 at 11:36 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Fri, 27 Aug 2010 10:14:30 -0500, Dmitry Karpeev <<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>> wrote:<br>
> Maybe Create/Destroy isn't the right solution, but there appears to be<br>
> some confusion<br>
> about the meaning of Get/Restore in this context.  It definitely<br>
> differs from VecGet/RestoreArray.<br>
> For example: there is no guarantee that subsequent DAGetXXXs,<br>
> punctuated by DARestoreXXXs,<br>
> will give one the same object.<br>
<br>
</div>Indeed, managing a pool has different semantics.  Is it worth looking<br>
for a less ambiguous/overloaded name?<br>
<br>
  Checkout/Checkin<br>
  Borrow/Return<br>
  Claim/Release<br>
<font color="#888888"><br>
Jed<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Kai Germaschewski<br>Assistant Professor, Dept of Physics / Space Science Center<br>University of New Hampshire, Durham, NH 03824<br>office: Morse Hall 245E<br>phone:  +1-603-862-2912<br>
fax: +1-603-862-2771<br><br>