[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: |
Fri, 20 Sep 2013 12:22:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
Hi,
On 2013-09-19 22:06, Rik wrote:
> 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?
I didn't, but I now updated to the current hg head (as of this morning)
and the behaviour is the same. If I enable all assert() calls (which I
already manually disabled in the places where most of the time was
spent) and do some typical calculation with my code, it takes nearly 50%
of the time (assert and deblank combined):
octave:2> profshow(profile('info'))
# Function Attr Time (s) Calls
----------------------------------------------------
123 assert 46.269 510057
125 deblank 25.949 510066
211 findMeshVertices 18.137 3
171 buildMatrices 5.205 5
310 __line__ 4.338 1690
312 __go_line__ 3.865 1690
15 nargin 2.531 2138678
75 find 1.990 539172
12 max 1.960 522487
16 binary == 1.857 2466308
tic/toc reports 155 seconds for the whole execution. The asserts in
question are within loops but only on simple conditions (which may
involve things like length() or indexing a vector, but not comparisons
of huge matrices or so).
> 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.
I think it should be even acceptable to replace the custom error message
by something like "assertion failed" without details if the user
explicitely specifies this via a configuration option for production
runs, no?
Here are two more tests: When I add a custom assert.m which is just an
empty function, I get a total time of 56 seconds and
# Function Attr Time (s)
------------------------------------------------------------
205 findMeshVertices 14.553
166 buildMatrices 5.239
306 __line__ 4.335
308 __go_line__ 3.844
223 cellfun 1.791
125 bdrygeom 1.448
182 ls2sd2 1.229
Even if assert is implemented like this:
function assert(cond)
if (~cond)
error ("assertion failed");
endif
endfunction
which has all the "base" functionality (at least the one I need/use),
then the time is still only 57 seconds with
# Function Attr Time (s)
------------------------------------------------------------
205 findMeshVertices 14.509
166 buildMatrices 5.222
306 __line__ 4.304
308 __go_line__ 3.714
223 cellfun 1.782
125 bdrygeom 1.466
182 ls2sd2 1.257
184 ls2sd2>dKKTsys 1.086
So what about simply adding an option that reduces assert() to basically
this implementation in case we just have a single argument? For my
situation, this would already improve it to the point that I wouldn't
any longer need to disable asserts manually. Of course it is trivial to
replace assert as I just did, but it would be great if this was possible
also with Octave's built-in version.
Yours,
Daniel
--
http://www.domob.eu/
--
Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
- Re: assert () taking long time, Rik, 2013/09/19
- Re: assert () taking long time,
Daniel Kraft <=
- Re: assert () taking long time, Rik, 2013/09/23
- Re: assert () taking long time, Daniel Kraft, 2013/09/24
- Matlab compatibility of assert (was: Re: assert () taking long time), John W. Eaton, 2013/09/24
- Re: Matlab compatibility of assert, Julien Bect, 2013/09/24
- Re: Matlab compatibility of assert, John W. Eaton, 2013/09/24
- Re: Matlab compatibility of assert, Julien Bect, 2013/09/24
- Re: Matlab compatibility of assert, Rik, 2013/09/24
- Re: Matlab compatibility of assert, John W. Eaton, 2013/09/24
- Re: Matlab compatibility of assert, Rik, 2013/09/24