MaplePrimes - comments on Post, subvectors as arguments

<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" version="2.0">
  <channel>
    <title>MaplePrimes - comments on Post, subvectors as arguments</title>
    <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments</link>
    <language>en-us</language>
    <copyright>2026 Maplesoft, A Division of Waterloo Maple Inc.</copyright>
    <generator>Maplesoft Document System</generator>
    <lastBuildDate>Sat, 13 Jun 2026 09:57:05 GMT</lastBuildDate>
    <pubDate>Sat, 13 Jun 2026 09:57:05 GMT</pubDate>
    <itunes:subtitle />
    <itunes:summary />
    <description>The latest comments added to the Post, subvectors as arguments</description>
    <image>
      <url>http://www.mapleprimes.com/images/mapleprimeswhite.jpg</url>
      <title>MaplePrimes - comments on Post, subvectors as arguments</title>
      <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments</link>
    </image>
    <item>
      <title>Alias</title>
      <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments?ref=Feed:MaplePrimes:subvectors as arguments:Comments#comment98793</link>
      <itunes:summary>&lt;p&gt;Rather than copying, you could also use &lt;a href='http://www.maplesoft.com/support/help/search.aspx?term=ArrayTools[Alias]' target='_new'&gt;?ArrayTools[Alias]&lt;/a&gt;.&amp;nbsp; For this example that is about twice as fast, however, because each call to Alias returns an rtable object (of about 140 bytes), the memory allocated is greater.&amp;nbsp; Maybe Alias could be extended to permit reusing a given rtable structure so that the memory usage is minimal.&lt;/p&gt;</itunes:summary>
      <description>The latest comments added to the Post, subvectors as arguments</description>
      <guid>98793</guid>
      <pubDate>Tue, 09 Nov 2010 22:22:20 Z</pubDate>
      <itunes:author>Joe Riel</itunes:author>
      <author>Joe Riel</author>
    </item>
    <item>
      <title>sometimes</title>
      <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments?ref=Feed:MaplePrimes:subvectors as arguments:Comments#comment98797</link>
      <itunes:summary>&lt;p&gt;Thanks, Joe.&lt;/p&gt;
&lt;p&gt;Yes, sometimes ArrayTools:-Alias is preferred. But sometimes it is not. One problematic case in when the rtable (Vector, Matrix, Array) has an indexing function or non-rectangular storage (eg. sparse) -- which Alias doesn't support.&lt;/p&gt;
&lt;p&gt;Another problem case is where the `f` acts in-place. That's not so relevent here but may pertain more to the parent post from which this post was branched.&lt;/p&gt;
&lt;p&gt;Another problem case may be when the `f` passes the object externally and is not designed to somehow figure out and communicate externally any offset of the Aliased object (w.r.t the original data object like V).&lt;/p&gt;
&lt;p&gt;And then there whole range of related issues when the original data object is a Matrix. Then the Alias offset may be a problem (possible worked around in other ways). Of course in that case Copying, if done in many function calls, may be more expensive.&lt;/p&gt;
&lt;p&gt;The theme is really how to avoid rtable creation &amp;amp; collection, if it can be avoided. Absolutely, there are other ways and means for that. It well be that different situations' particulars make some ways of approaching the memory use issue better than others. No size fits all!&lt;/p&gt;
&lt;!--break--&gt;
&lt;p&gt;Dave Linder&lt;br&gt; Mathematical Software, Maplesoft&lt;/p&gt;</itunes:summary>
      <description>The latest comments added to the Post, subvectors as arguments</description>
      <guid>98797</guid>
      <pubDate>Tue, 09 Nov 2010 23:12:25 Z</pubDate>
      <itunes:author>Dave L</itunes:author>
      <author>Dave L</author>
    </item>
    <item>
      <title>memory management, garbage collection, and ArrayTools:-Copy</title>
      <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments?ref=Feed:MaplePrimes:subvectors as arguments:Comments#comment98819</link>
      <itunes:summary>&lt;p&gt;Dear Dave,&lt;/p&gt;
&lt;p&gt;This is the clearest and most didactic tutorial I've read!&lt;/p&gt;
&lt;p&gt;I think your post (and additional remarks in the follow-up) should be promoted to the "tutorial" section, if there is one -- there was a talk a little while ago about creating a "databank" of didactic posts, a sort of complement to the Help files, your post belongs right there.&lt;/p&gt;
&lt;p&gt;I have often found myself doing exactly the kind of inefficient garbage collection you describe. While I was aware of the problem, I had no idea how to begin addressing the problem. Now I've got a much better idea of what's at stake.&lt;/p&gt;
&lt;p&gt;A small thing I have wondered about, whichever of these two is an appropriate gauge of "efficiency" (whatever that means)? kernelopts(bytesalloc) versus kernelopts(bytesused). Your code only computes bytesused. (P.S. the 4.5MB figure you refer to, is that the bytesalloc? Quote: "&lt;span class="mainBody document"&gt;Maple only had to allocate about 4.5MB in total at any given moment")&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;A side remark, the syntax of&amp;nbsp; ArrayTools:-Copy(10000,V,3,1,C,0,1); is definitely something to be learned rather than guessed.&lt;/p&gt;
&lt;p&gt;Thanks a lot,&lt;/p&gt;
&lt;p&gt;Patrick.&lt;/p&gt;
&lt;p&gt;&lt;span class="mainBody document"&gt; &lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt; &lt;/span&gt;&lt;/p&gt;</itunes:summary>
      <description>The latest comments added to the Post, subvectors as arguments</description>
      <guid>98819</guid>
      <pubDate>Wed, 10 Nov 2010 13:03:11 Z</pubDate>
      <itunes:author>PatrickT</itunes:author>
      <author>PatrickT</author>
    </item>
    <item>
      <title>measuring performance</title>
      <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments?ref=Feed:MaplePrimes:subvectors as arguments:Comments#comment98835</link>
      <itunes:summary>&lt;p&gt;&lt;a href="http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments#comment98819"&gt;@PatrickT&lt;/a&gt; Thanks, Patrick -- I'll take didactic in the sense of pedagogic rather than pedantic. ;)&lt;/p&gt;
&lt;p&gt;The result from kernelopts(bytesused) is an indicator of how much memory has been used and re-used. A high figure usually means that a lot of garbage collection has taken place.&lt;/p&gt;
&lt;p&gt;The results from kernelopts(bytesalloc) show how much memory Maple's kernel has had to allocate or take from the operating system (OS). Since memory is not returned to the OS without a Maple `restart`, the value of bytesalloc at any given time shows the total memory that Maple has had to allocate since the last `restart`. But not all of that memory may be currently used for storing objects -- some of it may be memory that has been cleared by garbage collection (gc).&lt;/p&gt;
&lt;p&gt;In the commandline interface, by default, a summary of memory use is printed (pretty much with each gc). If you see a slew of such printed messages then you can interpret this as meaning there is a lot of garbage collection happening. These messages can be turned off with the kernelopts(printbytes) setting. These messages look like this:&lt;/p&gt;
&lt;pre&gt;memory used=45.8MB, alloc=38.4MB, time=20.47&lt;br&gt;memory used=76.3MB, alloc=38.4MB, time=34.56&lt;br&gt;&lt;/pre&gt;
&lt;p&gt;Generally, if you see that "memory used"=bytesused message frequently in your comamndline session, with values growing large, then your computation is using and re-using a lot of memory. Objects are being created and discarded.&lt;/p&gt;
&lt;p&gt;In contrast, in the Standard GUI the status bar at bottom shows something akin to bytesalloc. It might be useful if the GUI were to also display (optionally, maybe off by default) the bytesused as another ticker value.&lt;/p&gt;
&lt;p&gt;It's not crystal clear how anyone should best use these things to measure "efficiency". If anything they are just rough guides of how Maple is using memory. There are more sophisticated tools for investigating the time and memory resources used by some code, such as &lt;a href='http://www.maplesoft.com/support/help/search.aspx?term=CodeTools,Profiling' target='_new'&gt;?CodeTools,Profiling&lt;/a&gt; and &lt;a href='http://www.maplesoft.com/support/help/search.aspx?term=exprofile' target='_new'&gt;?exprofile&lt;/a&gt; . It's not really true to say that these are tools for measuring "efficiency" or "performance", unless we agree on what those terms mean. I'll try to explain some of the difficulty:&lt;/p&gt;
&lt;p&gt;Suppose that you are doing a lot of computations. Suppose that Maple has allocated enough memory, and from a given point onward can simply recollect and re-use memory already allocated. In that case you likely won't see subsequent change in bytesalloc. So, in a sense, bytesalloc is merely a crude way to tell how much extra memory is needed for a given task, provided that you measure the task right at the start of the session, that memory has not yet been allocated and cleared, etc, etc. There are lots of caveats here to making sense in interpreting that measurement's change.&lt;/p&gt;
&lt;p&gt;One way to compare performance is to do what you did in the parent post from which this current post was branched. You separately do each short simple variant, as quickly after restart as you can (just setting up data and required routine code beforehand). That seems like a practical and simple way to inspect time and memory use and allocation requirements of the particular method. You avoid the supposed pitfall of measuring two alternate methods back to back. The danger of measuring computations done back to back is that the second method's attempt might indicate spurious measurements due to garbage collection occuring &lt;em&gt;during&lt;/em&gt; the calculation. Here's something I've seen done, where both taskA and taskB generate a lot of garbage that just happens to only get collected during the computation that follows them(!):&lt;/p&gt;
&lt;pre&gt;&amp;gt; restart:&lt;br&gt;&amp;gt; time( taskA );&lt;br&gt;                      2.0 sec&lt;br&gt;&amp;gt; time( taskB );&lt;br&gt;                     15.0 sec &lt;br&gt;&lt;/pre&gt;
&lt;p&gt;And the faulty conclusion is that taskA is faster than taskB. The truth might only emerge if you happen to observe:&lt;/p&gt;
&lt;pre&gt;&amp;gt; restart:&lt;br&gt;&amp;gt; time( taskB );&lt;br&gt;                      1.0 sec&lt;br&gt;&lt;br&gt;&amp;gt; time( taskA );&lt;br&gt;                     13.0 sec&lt;br&gt;&lt;/pre&gt;
&lt;p&gt;There's a related but rare scenario, where the huge memory allocation of the first task makes the second task require the OS to swap out memory.&lt;/p&gt;
&lt;p&gt;It's tempting to take that danger into consideration and conclude that wholly separate test runs are the best way to measure performance. It's tempting to assume that only a clean session will get performance measured clearly.&lt;/p&gt;
&lt;p&gt;But, really, isn't it more the case that we want best performance under typical usage by the user? The user &lt;em&gt;might&lt;/em&gt; call some routine, typically, in mid-session. Maybe it is better to do timings only after Maple's done lots of earlier work, allocation and creating garbage galore. How do methods compare at that point, in this more typical scenario? Why not do test runs more like taskA, taskB, taskA, taskB, etc? Possibly with loops. Other variations on this are also possible. It's not even true that this alternative measurement scheme is better, since it might not in fact be typical usage. Which way you choose to measure performance could depend on which way it will get used.&lt;/p&gt;
&lt;p&gt;I need to point out that garbage collection is not inherently bad. There are lots of problems for which it is natural in pragmatic computational implementations. If Maple had no memory management scheme then it would have to keep allocating memory for every new object, and solving far fewer problems would be possible. In that sense, memory management makes Maple more efficient, as it can thus re-use memory instead of requiring ever more allocation. I've been discussing that transient object creation is sometimes avoidable. Also, it may inadvertantly sound like I'm saying that all this extra cost is in `gc`. But it's likely that a great deal of the cost is in the creation (and not just the disposal) of the temporary objects. The bytesused value can be, however, an indicator that much object creation &lt;em&gt;and&lt;/em&gt; disposal is occuring.&lt;/p&gt;
&lt;p&gt;Dave L&lt;/p&gt;</itunes:summary>
      <description>The latest comments added to the Post, subvectors as arguments</description>
      <guid>98835</guid>
      <pubDate>Wed, 10 Nov 2010 22:52:42 Z</pubDate>
      <itunes:author>Dave L</itunes:author>
      <author>Dave L</author>
    </item>
    <item>
      <title>Greek -&gt; didaktikós -&gt; teach</title>
      <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments?ref=Feed:MaplePrimes:subvectors as arguments:Comments#comment98840</link>
      <itunes:summary>&lt;p&gt;I meant it in the Greek sense, which is all good. Not sure how the English language came to distort the original meaning. Perhaps English speakers don't like to be taught? I love it and I've greatly enjoyed your lessons Dave, thanks.&lt;/p&gt;</itunes:summary>
      <description>The latest comments added to the Post, subvectors as arguments</description>
      <guid>98840</guid>
      <pubDate>Thu, 11 Nov 2010 01:09:00 Z</pubDate>
      <itunes:author>PatrickT</itunes:author>
      <author>PatrickT</author>
    </item>
    <item>
      <title>BlockCopy</title>
      <link>http://www.mapleprimes.com/posts/98790-Subvectors-As-Arguments?ref=Feed:MaplePrimes:subvectors as arguments:Comments#comment98846</link>
      <itunes:summary>&lt;p&gt;One more thing...&lt;/p&gt;
&lt;p&gt;Matrices were mentioned. They present a difficulty for  ArrayTools:-Copy since copying a sub-Matrix could require many separate  calls (eg, once for each row, or for each column).&lt;/p&gt;
&lt;p&gt;But in Maple 12 the routine &lt;a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=ArrayTools/BlockCopy"&gt;ArrayTools:-BlockCopy&lt;/a&gt; appeared, which addressed this issue for Matrices and Arrays.&lt;/p&gt;
&lt;p&gt;These copying routines can also help avoid transient rtable object  creation in situations other than as arguments to functions. Consider  indexed assignment. Eg, for Matrices `New` and `Old`&lt;/p&gt;
&lt;pre&gt;  New[35..105,15..165] := Old[40..110,20..170];
&lt;/pre&gt;
&lt;p&gt;In the above example, Maple creates a new sub-Matrix which is  Old[40..110,20..170]. Such rtable indexing syntax is convenient, but it  uses more resources that are strictly needed. The (anonymous) temporary  sub-Matrix is created, used for the copy, and then since it it no longer  referenced it should be up for grabs at the next gc sweep. This is the  kind of opportunity where BlockCopy is beneficial. It can be an  efficient alternative to the above syntax.&lt;/p&gt;
&lt;pre&gt;restart:
M:=Matrix(6000,6000,datatype=float[8]):
N:=Matrix(6000,6000,datatype=float[8]):
kernelopts(bytesalloc);
                           576786288

st:=time(): M[2..5999,2..5999]:=N[2..5999,2..5999]: time()-st;
                             0.110

kernelopts(bytesalloc);
                           864594320

restart:
M:=Matrix(6000,6000,datatype=float[8]):
N:=Matrix(6000,6000,datatype=float[8]):
kernelopts(bytesalloc);
                           576786288

st:=time():
ArrayTools:-BlockCopy(N,6000,6000,6000,5998,M,6000,6000,6000,5998);
time()-st;
                             0.063

kernelopts(bytesalloc);
                           576786288
&lt;/pre&gt;
&lt;p&gt;The optional arguments and calling sequence of ArrayTools:-BlockCopy is even more beautiful than that of ArrayTools:-Copy.&lt;/p&gt;
&lt;p&gt;For large amounts of float[8]/complex[8] copying routines like  BlockCopy should be fast, since they are often making calls to compiled  BLAS functions which are tuned to the L1/L2 cache (so as to avoid  misses).&lt;/p&gt;
&lt;p&gt;Maple does not create any new object for the "indexed" syntax used on the LHS of that assignment statement.&lt;/p&gt;
&lt;p&gt;When I first read of the "Programmer indexing" on the &lt;a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=rtable_indexing"&gt;rtable indexing help page&lt;/a&gt; there appeared a glimmer of hope that super efficient rtable-Aliasing  might get invisibly tied into the new round-bracket syntax. That might  have allowed avoiding all such temp object creation when doing rtable  indexing on the RHS of assignment statements. But it is not so  implemented, mostly because indexing functions, non-rectangular  storage, and the need for external passing make it unworkable in  general. Ah, well.&lt;/p&gt;
&lt;!--break--&gt;
&lt;p&gt;Dave Linder&lt;br&gt; Mathematical Software, Maplesoft&lt;/p&gt;</itunes:summary>
      <description>The latest comments added to the Post, subvectors as arguments</description>
      <guid>98846</guid>
      <pubDate>Thu, 11 Nov 2010 10:19:39 Z</pubDate>
      <itunes:author>Dave L</itunes:author>
      <author>Dave L</author>
    </item>
  </channel>
</rss>