octave-maintainers
[Top][All Lists]
Advanced

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

Re: assert() taking long time


From: Daniel Kraft
Subject: Re: assert() taking long time
Date: Thu, 19 Sep 2013 17:16:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130827 Icedove/17.0.8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.  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

- -- 
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
- --
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSOxVZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5MDFDNTIxNjA1MzcxRDJBRjA3MTVBMEU0
RDk0NkVFRDA0RjdDRjUyAAoJEE2Ubu0E989SdH8P/3XODckpjC1H7/exKk6HkYpr
jiRuvxBR8QRry3itwBqvfh29CTd2+JH/FD6GB8Um4J3kIF3rd6NpM41oNX3TnXeC
SoGJUbZbvbmqH93yAUn9grNht0jlnxCrfXfbwFOnRtjBkhrgM2FWcsl8ZJJNNctd
npNO0ajmn0wlMq6entAHUybREEwC8BFTiD/iUjbqesw2D19PDE1oxaFlDoqvVZvN
L/E5sxVYg+LfvX7ngHJboVZYALO6N1KR8wXEOfViluaPi8RGK+9ZLVqMplbW/Uv9
chpClU1w5eQRQJTi11w8P/ROtSbH/SqhlFVqeStSjwqc6EYzFLMmhzopeGu+AQCb
SAo4YGK+WkxzjRisb+vv9aLrXOV6E/DS6oXax6Ngqz+QrSz5mdcEH/wu2jnvvdMb
7S89HTMKKpAVwqndC3JUa6vm/HJDO5/VCUjh2TlS6/eZps8B9sKz8gMBLs1RDHTu
CIq+k+a0Vl9PlwyUR1AV3hWNfxsyueSB5BdaKBT7JMKSqLH/SseITdudc9B2t3PQ
oxvub7m3Ya/GcbMwIU5ZsLbsJA0SBuR76uVTi6BiO7ruH0xY9/QKdFR8HMzZkpcG
kAKBticvEYBpcW70195h14rLmyZiy8iQnBNck3/GWSIb3wreGrzoUX3CyPH54gQf
2Eh7+ZqD8gYU/8CF2om6
=5HXq
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

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