1. 2.4 problems
- Posted by Andy Serpa <ac at onehorseshy.com> Jun 08, 2003
- 407 views
Hello, Another keyword Borland doesn't like: "asm" Used as a variable name in fptr.e, Borland won't compile the translated code. I'm also having another problem with 2.4 with memory allocation or possibly with sequence concatenation. Haven't nailed it down yet, but in certain circumstances when using the "compress()" function in database.e my program comes to a dead halt. (I'm not actually using database.e or EDS -- I stole the function to use for other things.) It hasn't really stopped completely, but it goes really slow (suddenly) and takes forever to return from the function (like many minutes for what should take a fraction of a second). Doesn't do it in 2.3. As yet, I'm unable to reproduce the problem with a simple example. The strange thing is, it doesn't slow down until I've already called the function successfully a few dozen times previously in the program. Anyway, I still think there are issues there somewhere. It acts the same way translated with either Watcom or Borland -- I got the impression that Borland does not use the new allocator? So maybe the problem lies with your changes to the "&" operator? You might want to look it over as I may not be able to isolate this...
2. Re: 2.4 problems
- Posted by Robert Craig <rds at RapidEuphoria.com> Jun 09, 2003
- 385 views
Andy Serpa wrote: > Another keyword Borland doesn't like: "asm" > > Used as a variable name in fptr.e, Borland won't compile the translated > code. Yes, I've got that one on my exclusion list for the 2.4 official Translator release. > I'm also having another problem with 2.4 with memory allocation or > possibly with sequence concatenation. Haven't nailed it down yet, but > in certain circumstances when using the "compress()" function in > database.e my program comes to a dead halt. (I'm not actually using > database.e or EDS -- I stole the function to use for other things.) It > hasn't really stopped completely, but it goes really slow (suddenly) and > takes forever to return from the function (like many minutes for what > should take a fraction of a second). Doesn't do it in 2.3. As yet, I'm > unable to reproduce the problem with a simple example. The strange > thing is, it doesn't slow down until I've already called the function > successfully a few dozen times previously in the program. Anyway, I > still think there are issues there somewhere. > > It acts the same way translated with either Watcom or Borland -- I got > the impression that Borland does not use the new allocator? Watcom, Borland and Lcc all use the Windows default heap now, and they all allocate/deallocate space in the same way. > So maybe the problem lies with your changes to the "&" operator? > You might want to look it over as I may not be able to isolate this... I hope you can narrow it down. I don't know of any other performance bugs like this in 2.4 beta, except for one that can only happen if you use a Euphoria-written .dll (reported by Euman, that bug has been fixed for the official release). Be careful that you are running 2.4 beta, not alpha. Thanks, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: 2.4 problems
- Posted by Robert Craig <rds at RapidEuphoria.com> Jun 09, 2003
- 367 views
Andy Serpa wrote: > The following rather strange program seems to do the trick: Thanks for the example. It runs fine on my 256MB XP system, but on my 64Mb ME system it stalls for an extremely long time on: s3 = {} I'll try to figure out what's happening. Probably the storage allocation/deallocation algorithm needs to be tweaked to handle this extreme case. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
4. Re: 2.4 problems
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 09, 2003
- 377 views
On Mon, 9 Jun 2003 16:18:42 +0000, Andy Serpa <ac at onehorseshy.com> wrote: <snip> >for i =3D 1 to 500000 do ^ i had to kill a zero on that ;-( {P233, 48MB, Eu 2.4 beta} >--s1 =3D {} ^^^ bizarre!!!=20 Correct me if I'm wrong, but that is a top-level statement executed exactly ONCE (when uncommented ) Bizzare, because variable s1 is not referenced *at all* after that point (I'm measuring just up to the --s2 =3D {} line, no further). Andy, Rob, just that *one* line uncomment made it run like a dog (TEN times slower: 130 seconds vs 13 seconds) on my PC. Bizzare, because code *NOT* referencing that variable, like I just said, runs ten times slower!! Andy: I think you have definitely found something . Pete