Re: Dramatic slowdown -ping Rob
- Posted by Mario Steele <eumario at trilake.net> Nov 30, 2004
- 585 views
I have actually found something of much intrest.... I do not have a copy of 2.4 readily at my disposal, but this test has come up with some.... shall we say, interesting points. This problem at hand, may be due to Heap Corruption as Pete suggested, but it may be not what your expecting. I'm running a AMD Athlon XP 2.16 GHz Proccessor with 192 Megs of ram, and for the original source code as given by Pete, the results are as follows: ex.exe (27): 0.110000 ex.exe (28): 0.110000 However, I was going to test this with exw.exe, and needed to throw in a pause before exiting execution, so I use my normal, while get_key() = -1 do end while to the end of the code, so I could see the results. However, I forgot I put this in, when I went to re-test the code on ex.exe, and found a surprising result.
constant START = time() constant INNER=27 sequence table table=repeat(repeat(0,INNER),1024) integer used used=1 for i=1 to 45000 do used+=1 if used>length(table) then table&=repeat(repeat(0,INNER),1024) end if table[used][5]=used end for printf(1, "Elapsed time: %f\n", time() - START) while get_key() = -1 do end while
One would belive this would return the same result as before, however, these are the results I got: ex.exe (27): 2.030000 ex.exe (28): 2.090000 Now, taking from Rob's own admitance, it seems to me, that it's not the actual execution that's resulting in these times, but instead, the backend may be corrupting the heap when it releases the memory before executing the IL code generated by the frontend. There's definatly something going on, for the interpreter to be generating this much of a diffrence between the original code, to 1 loop inheritance added, with absolutely no code inside actually executed, except for get_key(). Just letting ya know, EuMario Pete Lomax wrote: > > On Sun, 28 Nov 2004 20:29:12 -0800, Robert Craig > <guest at RapidEuphoria.com> wrote: > > >As promised, I looked into the performance issue raised > >by Pete Lomax a while back. I don't think there is any > >bug in Euphoria itself (ref counts etc.). > >I rather think WATCOM's storage > >allocator for DOS has some very quirky behavior. In exw.exe > >I don't use the WATCOM allocator, I use Microsoft's. > Thanks for looking into this. Now I know it's a problem in ex rather > than exw, I'm no longer overly concerned about it. > >I earlier reported no problem with ex.exe for 2.5, > >but I think I must have been using exw.exe for 2.5. > >exw runs the code below very fast regardless of the > >size of the sequences. People noticed a big slowdown > >with ex.exe when moving from 27 to 28. I believe that's because > >I allocate 50% more space when the size becomes 28. > >For speed in handling small sequences, I map to a set of > >standard memory block sizes: > >16, 24, 32, 48, 64, 96, 128 bytes, 192 bytes, 256 etc. > >I think 27 would need 128, while 28 would need 192. > > > >However, strangely enough, when the size is increased from 28 to > >100, it runs really fast, even though more processing is being > >done by Euphoria. > Sounds to me like Watcom has a problem with 192, which is not all that > surprising since few C programs are likely to allocate tens of > thousands of blocks of (just) that size. You've probably thought of > this already, but you might want to consider avoiding the problem in > ex by removing the 192 size (ie just in ex, leave it in exw and exu)? > As I said, it does not really bother me personally, but I know that > "speed is something of an obsession for you". > > Regards, > Pete