octave-maintainers
[Top][All Lists]
Advanced

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

Re: assert () taking long time


From: Rik
Subject: Re: assert () taking long time
Date: Thu, 19 Sep 2013 13:06:24 -0700

On 09/19/2013 10:00 AM, address@hidden wrote:
Message: 2
Date: Thu, 19 Sep 2013 17:16:41 +0200
From: Daniel Kraft <address@hidden>
To: "John W. Eaton" <address@hidden>
Cc: address@hidden
Subject: Re: assert() taking long time
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

********* *BEGIN ENCRYPTED or SIGNED PART* *********

On 2013-09-19 16:54, John W. Eaton wrote:
> On 09/19/2013 10:13 AM, Jordi Guti?rrez Hermoso wrote:
>> On Thu, 2013-09-19 at 09:35 +0200, Daniel Kraft wrote:
>> 
>>> In C/C++, one can easily disable assertions using the
>>> preprocessor.  I think it would be great if Octave could
>>> provide a similar feature, where asserts could be executed or
>>> ignored depending on a switch similar to debug_on_error and all
>>> those options.
>> 
>> I like this idea. Looking forward to your patch. :-)
>> 
>> - Jordi G. H.
>> 
>> 
> 
> Not so fast, eh?
> 
> In Octave, assert is a function just like any other.  It is
> perfectly valid for you to write a class that has an assert
> function, or to replace the default assert function with your own.
> I suspect the overhead of calling assert is primarily about
> executing the code that makes up the argument to the assert
> function, then looking up the appropriate function to call.
> Further, assert may be a variable name. So you can't just have the
> parser detect a symbol with the name assert and blindly turn it
> into a no-op.
Yes, I'm aware of that fact and it won't be a totally straight-forward
fix.  For my actual cases, a lot of time seems to be spent also in
deblank which is called by assert.  I don't really know all the
details about how assert() does what it does, but that seems to be
something where one could at least either optimise assert (for certain
input combinations, like just a condition?) directly without losing
any functionality, or immediately abort the function execution when
assertions should be disabled.
9/19/13

Daniel,

Are you working from the development version of Octave in the Mercurial repository?  The assert function has been massively re-written on the development branch and it may, or may not, still have performance issues.  Assuming you are using the latest assert.m, what kind of performance hit are you seeing?  Is it 1% or 10% of your script running time?

For the version in the repository, the calls to deblank could easily be avoided.  We pre-calculate an error message using deblank, but only print it if there is a problem.  You could move the calculation of the message inside the error checking code so that it is only generated if needed.  Look for the variable "in" in the code; It is used in two if branches so you would need to duplicate it for each if body, but that is simple.

--Rik

  Maybe I'll try out how much of a
difference that would already make, even though it is not optimal
(there's still the overhead of calling the assert function, the
condition is still evaluated and so on).  I presume this would go
without too much disturbance to the Octave core?

If this is not enough, I know that the parser can't rely on assert()
being actually the assert function that should be ignored in some
cases -- but would it be ok to still do so conditionally (default to
off of course), when those who enable the option do so on their own
responsibility?  Furthermore, couldn't the interpreter -- after
resolving the target of a function call -- check whether the function
being called is the intrinsic assert or something else?  So that only
calls to assert() proper will be disabled.

What do you think?

Yours,
Daniel

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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