1. Allocate() Affecting execution speed.

Hi,

I have the following piece of code:

-----
    include get.e
    include machine.e

    sequence seq
    atom     misc, start, stop, block

    block = allocate( 1024 )

    start = time()
    for i = 1 to 20000 do
        seq = {}

        for j = 1 to 64 do
            seq &= {4,5,6}
        end for

    end for
    stop = time()

    printf(1, "Time: %f\n", (stop - start) )

    free(block)

    misc = wait_key()
-----

If I don't allocate the block of memory, on my machine, the above code
executes in ~0.5 seconds.

If I allocate a block of 1k, and use a value from 38 to 76 in the 'for j'
loop the code executes in ~1.2 to ~2.6 seconds.

If I use a larger block size and/or use a value outside the range mentioned
above, the time the code takes to execute scales as would be expected (i.e.
37 = ~0.32, 77 = ~0.57)

What am I not seeing? I'm not using the block for anything so why should
that effect the speed of the code?

If everything is ok, does anyone have any insight or ideas as to what could
be going on inside Euphoria that would be causing the slow down?

The PERFORM.DOC talked about the size of the cache possibly affecting
speed; could that have something to do with it?

I'm using Euphoria 2.1, complete edition. The behavior is the same under
Windows 98 and DOS.

I have also tested this under the 2.2 beta; the times where different but
the behaviour was identical.

Thanks in advance,
David Guy

new topic     » topic index » view message » categorize

2. Re: Allocate() Affecting execution speed.

David Guy writes:

> What am I not seeing? I'm not using the block for anything
> so why should that effect the speed of the code?

The code that you posted seems to fit the criteria for a
performance bug that was fixed for version 2.2
(Win, DOS and Linux). Basically, you are growing and
regrowing a sequence over and over. When I run your
code under 2.2 Beta I get a time that is 10x faster than
under 2.1 on the same machine.

I did notice that when the block is allocated
the time goes up rather surprisingly on 2.1, and to
a much smaller extent on 2.2 Beta. I also noticed
that when I allocated *two* 1024-byte blocks instead of
just one, the time went back to normal.

Since the time only varies by 10% on 2.2 Beta I don't
plan to investigate it further. I assume that by allocating
the extra block you have changed the order of blocks
on malloc's free list, thereby affecting the speed at which
malloc can find new blocks to use with the growing sequence.

On 2.1, as I recall, some weird and very inefficient stuff happens
in this situation, and I don't want to go back and analyze it.

Regards,
     Rob Craig
     Rapid Deployment Software
     http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu