[Top][All Lists]

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

Re: [Bug-apl] Performance problem with simple program

From: Juergen Sauermann
Subject: Re: [Bug-apl] Performance problem with simple program
Date: Sat, 10 Oct 2015 13:47:17 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Hi Elias,

good idea, I will look into this.
Do you have your code somewhere?

I believe the proper way is to stop after the tokenizer stage if the result is a single APL value.
That way no extra processing is performed and parsing and creation of an execution context
(push/pop )SI stack etc.) is avoided.

/// Jürgen

On 10/09/2015 04:36 PM, Elias Mårtenson wrote:
Hello Jürgen,

I am assuming that I am not alone in commonly using ⍎ for the purpose of parsing a number embedded in a string as APL (i.e. something analogous to PARSE-INTEGER in Lisp, or strtol() in C).

With that in mind, I made a small change to Bif_F1_EXECUTE::execute_statement() which checked if the string is a "pure" number. In my test case, I simply checked if all characters where digits, but it should be slightly more clever in a production grade version.

If the string statement is a pure number, then I simply circumvented the entire parsing machinery and directly returned the number itself. In doing so, I got a 4× performance improvement, even though I incorrectly allocated an array to put the result in, which is not correct. Returning a pure number would make it even faster, but for some reason it crashed when I tried returning Token(TOK_APL_VALUE1, the_number).

I think it makes sense to add this performance fix. The method already begins with a call to statement.remove_leading_and_trailing_whitespaces(), so if the check were to be done at the same time the performance impact would be minimal, while making ⍎ useful as a number parsing function.


On 7 October 2015 at 22:30, Juergen Sauermann <address@hidden> wrote:
Hi Peter,

I guess when
L⍟(|R)+R=0 is integer then ⌈ and ⌊ would be the same
and then the  1+⌊ is different from ⌈.

/// Jürgen

On 10/07/2015 04:19 PM, Peter Teeson wrote:
Re: encode
I was wondering why the APL Lang Ref Manual p.161 shows:

Why would this not be just as correct?

and so 
two symbols less……..<grin>

reply via email to

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