[992] in Coldmud discussion meeting

Re: [COLD] Possible optimization idea..

daemon@ATHENA.MIT.EDU (Mon May 6 00:43:39 1996 )

Date: Sun, 5 May 1996 23:34:17 -0400 (EDT)
From: James Deikun <james@sanban.cis.pitt.edu>
To: Brandon Gillespie <brandon@tombstone.sunrem.com>
cc: coldstuff@cold.org
In-Reply-To: <Pine.BSF.3.91.960502164226.17688C-100000@tombstone.sunrem.com>



On Thu, 2 May 1996, Brandon Gillespie wrote:

> the end result is very large.  The idea would be to provide an 
> 'initializer' function of sorts, for this case called 'new()' where you 
> specify the data type and the anticipated size.  The driver can ignore 
> this directive, or it can take it into account--calling 'new()' will 
> never throw an error, and may simply be equivalent to doing 'bar = "";'.  

To me it seems like there are better solutions, and they'd be easier to 
implement in some cases, as well as being useful for other purposes 
besides this.  Read on for said solutions.

As an example to get started with, I would write your exapmle code:

>     images = ["008-123", "008-141", ..];
>     serv = "<img src=\""+ $sys.primary_server() +"/images/catalog/";    
>     line = "";
>     for i in (images)   
>         line += t + i + ".gif\">\n";

as

>     images = ["008-123", "008-141", ..];
>     serv = "<img src=\""+ $sys.primary_server() +"/images/catalog/";
>     t = ".gif\">\n" + serv;    
>     line = serv + $string.join(t, images) + ".gif\">\n";

where $string.join is a native method that does one pass measuring, then
allocates the result, then does another pass copying the strings in.

Of course, this doesn't illustrate the solution fully.  Along with 
$string.join there would be a couple of other new native methods, like 
$list.flatten(), implemented similarly.  Further, there would be a new 
loop construct:

  map <var> in <expr> to <placeholder> in <resultvar> {
  }

(Feel free to use your own syntax, of course.)

A "map" would allocate a list the size of <expr> (assumed to be a list, 
die with ~type if not), loop through the enclosed statements once for 
each index position of <expr>, each time placing the <index>th element of 
<expr> in <var> before the statements are run, and putting the value of 
<placeholder> into the <index>th position of <resultvar> afterward.

"map" would be useful for times when you want to do some arbitrary thing 
to n values without gradually building up a list to hold them.

The advantages of this solution over new() is that:

  a) the programmer doesn't have to guess about memory requirements
  b) it's generally more transparent, often even than the code that would
     be used right now.

The only disadvantage I see is:

  a) you'd have to implement more stuff.

Personally, though, I'd like to see "map" happen for a lot more reasons than 
just this problem, and I'm sure that goes for some other people too.

Oh, the other thing: none of these constructs would ever allocate more 
memory at once than a could construct just by changing one element of a 
value they already have.  No one could try to "new" something with a 
size of $maxint, etc.

>       if (!$sys.is_admin(sender())) {
>           for line in (code) {
>               if (match_regexp("[^\.a-z_]new\(", line))
>                   throw(~invfunc, "Only administrators may use new()");
>           }
>       }

btw, this regexp is broken, since it'll kill a verb that contains 
'"new("' -- or itself, though clearly neither uses (or at least, need 
use) "new".

>   new() can also be a problem if the person coding with it is not
>   aware of how references are handled.  If they are using it in a
>   situation where the string would simply be copied anyway, it could
>   end up creating slower code..

Oh, that's another good thing about my solution: you NEVER end up copying 
things (or at least, the things you're specifically working with) anyway 
when using the functions/constructs I propose.  Or at least, I can't 
think how.

> Comments?  Is this too low a level of functionality for ColdC?  It is 
> simply a hinting mechanism intended for optimization, not necessarily a 
> direct memory allocation system like in other languages...

Well, actually, yes, I think it is too low-level.  Stuff like this at 
least ought to be handled 'out of line' (like pragmas or something) 
instead of cluttering up the code per se.

--
James "never count your bytes before they've hatched" Deikun
(defender of the silver derby, dry cleaner for the stars)