octave-maintainers
[Top][All Lists]
Advanced

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

Re: slow char({str})


From: Jaroslav Hajek
Subject: Re: slow char({str})
Date: Wed, 24 Jun 2009 06:34:13 +0200

On Wed, Jun 24, 2009 at 5:31 AM, Daniel J Sebald<address@hidden> wrote:
> Jaroslav Hajek wrote:
>>
>> On Sun, Jun 21, 2009 at 7:33 PM, Ben Abbott<address@hidden> wrote:
>>
>>> I noticed a substantial amount of time is needed to convert a cell string
>>> into a string
>>>
>>> octave:50> tic; char ({repmat("a", [1, 100000])}); toc
>>> Elapsed time is 11.9 seconds.
>>>
>>> but ...
>>>
>>> octave:51> tic; char ({repmat("a", [1, 100000])}{1}); toc
>>> Elapsed time is 0.001117 seconds.
>>>
>>> Can someone with skilled in c++ take a look?
>>>
>>> Ben
>>>
>>
>>
>> Please check
>> http://hg.savannah.gnu.org/hgweb/octave/rev/4ff6f8efdda2
>>
>> also transplanted into 3.2.x.
>>
>> thanks
>
> Very nice Jaroslav.  Which of these changes is the speedup coming from?
>  This hunk
>
> -       elem (i, j) = s[i][j];
> +       elem (i, j) = si[j];
>
> shouldn't have been too much as there is only a little extra computation in
> the indexing before the change.

No. In fact, this *was* the bottleneck, changing a linear complexity
operation to quadratic one. Welcome to the world of COW magic. The
expression s[i][j] forces a copy of the whole string, *for each j*.
This could be avoided if Array<T>::elem () const returned const T or
const T& rather than just T. Only Array<std::string> has this issue,
though.
Many Octave classes are COW, and carry similar dangers. They are
mostly avoided by using const qualifiers wherever possible. This is a
good idea anyway, so I don't regard the current state as really bad.
If you ignore const-ness, things will work, but you may lose
performance.

>  From the looks of all_strings, I'd guess
> this is the important change:
>
> -      string_vector s = matrix(i).all_strings ();
> +      const string_vector s = strvec_queue.front ();
> +      strvec_queue.pop ();
>
> The member function ::all_strings() isn't used too often.  Would it make
> sense to remove ::all_strings() and replace it's use with similar mods?
>
> Dan
>

The queue is to prevent the all_strings() conversion being called
twice. Yes, it is a bit unfortunate that joining a cell containing
only character arrays requires converting them to strings and then
converting back. The problem is that all_strings() is actually used
for two different purposes - converting a variable to a vector of
strings, and joining+padding. Improvements are surely welcome.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

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