1. Allocate() Affecting execution speed.
- Posted by David Guy <dguy at MINDSPRING.COM> Dec 30, 1999
- 471 views
- Last edited Dec 31, 1999
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
2. Re: Allocate() Affecting execution speed.
- Posted by Robert Craig <rds at ATTCANADA.NET> Dec 30, 1999
- 442 views
- Last edited Dec 31, 1999
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