octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: f(end) feature?


From: John W. Eaton
Subject: Re: f(end) feature?
Date: Tue, 31 Dec 2002 19:34:10 -0600

On 31-Dec-2002, Paul Kienzle <address@hidden> wrote:

| On Tue, Dec 31, 2002 at 04:31:48PM -0600, John W. Eaton wrote:
| > 
| > Since we save and restore the global pointer with the unwind protect
| > stack, it should work correctly for recursion to any depth.
| 
| So we pay for the feature even if we are not using it?  It's worth
| it as far as I'm concerned, and perhaps even cheaper than doing
| a call to a builtin function like length() or size().

Yes, but at least it works.  The cost is:

  Pass a pointer in each call to tree_argument_list::convert_to_const_vector
  even if it is not needed.

  In convert_to_const_vector, do

    bool stash_object = (object && object->is_constant ());

    if (stash_object)
      {
        unwind_protect::begin_frame ("convert_to_const_vector");

        unwind_protect_ptr (indexed_object);

        indexed_object = object;
      }

  at the beginning of the function,

    index_position = (len == 1) ? -1 : k;

  for each element of the argument list, and then

    if (stash_object)
      unwind_protect::run_frame ("convert_to_const_vector");

  at the end of the function.

Most of the overhead is in handling the unwind_protect stack.  To do
better, we could try to mark expressions that might actually need to
have the global variables set, then only do the save/restore for those
expressions that have been marked.  This would be similar to your idea
of modifying the parse tree to insert some code where needed.  I'll
see whether that would be easy to do.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]