1. Interpreter startup speed
- Posted by Jason Gade <jaygade at yahoo.com> Aug 18, 2006
- 697 views
Al Getz wrote: > > Hello again, > > I forgot to mention one thing before that affects only programs using > v2.5 and not v2.4 . > That is, the time to open a file is much longer with the 2.5 version > and that is not good on my system. I have a decent system and it's > still too slow. > > I realize that compiling everything before running has some advantages, > but it takes away from the time to open and it also doesnt allow you > to put up a splash screen while waiting for the rest of the program > to run. > > Perhaps a solution would be simple: > Divide the compile phase into two parts: > 1. First complile a small section of the code to allow a user > to put up a small splash screen to tell the user it's opening. > 2. Compile the rest of the code as usual. > > Doing this wouldnt be hard at all, and would increase the apparent speed > of the language for many users. > > When using a large library it just takes too long to open the way > it is now so something should be done. Who wants to wait for the > entire lib to compile? Not me :) > > I dont know how the initial code would be sectioned off, perhaps with > START: > --initial code here > :END > > or whatever really. ANYTHING to get rid of this annoying delay. > > > Al > > E boa sorte com sua programacao Euphoria! > > > My bumper sticker: "I brake for LED's" > I split this topic off... Reading your message I had a thought. Previous versions of Euphoria used incremental compilation I believe. 2.5 changed that. Now I haven't had any problems with it but I remember a lot of complaints from others. Since Rob is including simple threading in the next release maybe the release afterwards could use that in the IL compiler itself where it compiles a bit in the background as it starts running the program. Maybe that would speed up the long load times that some people experience. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
2. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 18, 2006
- 677 views
Jason Gade wrote: > > Al Getz wrote: > > > > Hello again, > > > > I forgot to mention one thing before that affects only programs using > > v2.5 and not v2.4 . > > That is, the time to open a file is much longer with the 2.5 version > > and that is not good on my system. I have a decent system and it's > > still too slow. > > > > I realize that compiling everything before running has some advantages, > > but it takes away from the time to open and it also doesnt allow you > > to put up a splash screen while waiting for the rest of the program > > to run. > > > > Perhaps a solution would be simple: > > Divide the compile phase into two parts: > > 1. First complile a small section of the code to allow a user > > to put up a small splash screen to tell the user it's opening. > > 2. Compile the rest of the code as usual. > > > > Doing this wouldnt be hard at all, and would increase the apparent speed > > of the language for many users. > > > > When using a large library it just takes too long to open the way > > it is now so something should be done. Who wants to wait for the > > entire lib to compile? Not me :) > > > > I dont know how the initial code would be sectioned off, perhaps with > > START: > > --initial code here > > :END > > > > or whatever really. ANYTHING to get rid of this annoying delay. > > > > > > Al > > > > E boa sorte com sua programacao Euphoria! > > > > > > My bumper sticker: "I brake for LED's" > > > > I split this topic off... > > Reading your message I had a thought. Previous versions of Euphoria used > incremental > compilation I believe. 2.5 changed that. Now I haven't had any problems with > it but I remember a lot of complaints from others. > > Since Rob is including simple threading in the next release maybe the release > afterwards could use that in the IL compiler itself where it compiles a bit > in the background as it starts running the program. Maybe that would speed up > the long load times that some people experience. > > -- > "Any programming problem can be solved by adding a level of indirection." > --anonymous > "Any performance problem can be solved by removing a level of indirection." > --M. Haertel > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > j. Hi Jason, Yes that's an interesting idea too, if we had control over what 'thread' gets compiled first. I would certainly do something like that. Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
3. Re: Interpreter startup speed
- Posted by Jason Gade <jaygade at yahoo.com> Aug 18, 2006
- 646 views
Al Getz wrote: > Hi Jason, > > Yes that's an interesting idea too, if we had control over what > 'thread' gets compiled first. I would certainly do something like > that. > > > Al > > E boa sorte com sua programacao Euphoria! > > > My bumper sticker: "I brake for LED's" > I'm not saying to compile certain threads of the user program first; I'm saying the interpreter should have a compiler thread and a interpreter thread. The compiler thread compiles the first few hundred (or thousand or whatever) instructions to IL code and then starts the interpreter thread. The compiler thread continues compiling in the background (well, both threads would be trading off really). If the interpreter thread ran out of instructions it would sleep for awhile until the compiler thread caught up again. Once the compiler thread finished converting the entire program to IL, it would exit leaving just the interpreter. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
4. Re: Interpreter startup speed
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 19, 2006
- 650 views
On Thu, 17 Aug 2006 20:10:23 -0700, Jason Gade <guest at RapidEuphoria.com> wrote: >Al Getz wrote: >> the time to open a file is much longer with the 2.5 version >> I realize that compiling everything before running has some advantages, >> 1. First complile a small section of the code to allow a user >> to put up a small splash screen to tell the user it's opening. >Previous versions of Euphoria used incremental compilation I believe. >it compiles a bit in the background as it starts running the program. I am convinced this will not help. One fact stares us in the face which is that Eu is about 8 times slower than C, for good reasons, and has been since Eu 1.0. Now Rob has just migrated the front end from C to Eu, and that is exactly what we (on slower machines) hit. Considering this in practical terms, imagine a 5,000 line program: include win32lib splash(blah) <5,000> lines of code WinMain(). There's a big problem: win32lib is itself some 45,000+ lines of code, so instead of a 15 second startup delay, you get a 13.5 second delay, the splash, and the main program 1.5 seconds after that. Personally, I feel that Rob was quite right to make this switch now, it is not his problem that this (found in the street) box cannot cope, nor, I expect, is he worried that I stick with 2.4 as a result. (btw, I kid not that on this box 2.5 takes 25 seconds to load win32lib, whereas 2.4 does it in just under 5. Bet few can worse that.) Regards, Pete
5. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 19, 2006
- 648 views
Jason Gade wrote: > > Al Getz wrote: > > Hi Jason, > > > > Yes that's an interesting idea too, if we had control over what > > 'thread' gets compiled first. I would certainly do something like > > that. > > > > > > Al > > > > E boa sorte com sua programacao Euphoria! > > > > > > My bumper sticker: "I brake for LED's" > > > > I'm not saying to compile certain threads of the user program first; I'm > saying > the interpreter should have a compiler thread and a interpreter thread. The > compiler thread compiles the first few hundred (or thousand or whatever) > instructions > to IL code and then starts the interpreter thread. The compiler thread > continues > compiling in the background (well, both threads would be trading off really). > If the interpreter thread ran out of instructions it would sleep for awhile > until the compiler thread caught up again. > > Once the compiler thread finished converting the entire program to IL, it > would > exit leaving just the interpreter. > > -- > "Any programming problem can be solved by adding a level of indirection." > --anonymous > "Any performance problem can be solved by removing a level of indirection." > --M. Haertel > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > j. Yes that sounds better :) Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
6. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 19, 2006
- 663 views
Pete Lomax wrote: > > On Thu, 17 Aug 2006 20:10:23 -0700, Jason Gade > <guest at RapidEuphoria.com> wrote: > > >Al Getz wrote: > >> the time to open a file is much longer with the 2.5 version > > >> I realize that compiling everything before running has some advantages, > >> 1. First complile a small section of the code to allow a user > >> to put up a small splash screen to tell the user it's opening. > > >Previous versions of Euphoria used incremental compilation I believe. > >it compiles a bit in the background as it starts running the program. > I am convinced this will not help. One fact stares us in the face > which is that Eu is about 8 times slower than C, for good reasons, and > has been since Eu 1.0. Now Rob has just migrated the front end from C > to Eu, and that is exactly what we (on slower machines) hit. > > Considering this in practical terms, imagine a 5,000 line program: > > include win32lib > splash(blah) > <5,000> lines of code > WinMain(). > > There's a big problem: win32lib is itself some 45,000+ lines of code, > so instead of a 15 second startup delay, you get a 13.5 second delay, > the splash, and the main program 1.5 seconds after that. > > Personally, I feel that Rob was quite right to make this switch now, > it is not his problem that this (found in the street) box cannot cope, > nor, I expect, is he worried that I stick with 2.4 as a result. (btw, > I kid not that on this box 2.5 takes 25 seconds to load win32lib, > whereas 2.4 does it in just under 5. Bet few can worse that.) > > Regards, > Pete > > Hi Pete, That's not exactly true unless you assume you HAVE to use that lib for the startup screen too. Also, if you put the link for CreateWindowEx() near the start of the file it would be available to the 'run' thread very quickly. Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
7. Re: Interpreter startup speed
- Posted by "Kat" <kat12 at coosahs.net> Aug 19, 2006
- 660 views
- Last edited Aug 20, 2006
Hey, Al, i have a silly suggestion: Why not run a "windows server" (ring any bells?), firing up a minimal child process as the splash, and when the main app code actually begins running it notifies the "server", which shuts down the splash process and brings the main to the fore, and then the "server" shuts down (or not, perhaps there's other things it could do later). Or, the splash is all the user starts, and the splash then immeadiately starts the main, which then uses PatRat's IPC to kill the splash (once the main is actually running) and come to foreground (or not). Either way, you can change the splash or the code and not affect the other. Kat
8. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 19, 2006
- 665 views
- Last edited Aug 20, 2006
Kat wrote: > > > Hey, Al, i have a silly suggestion: > > Why not run a "windows server" (ring any bells?), firing up a > minimal child process as the splash, and when the main app code > actually begins running it notifies the "server", which shuts down > the splash process and brings the main to the fore, and then the > "server" shuts down (or not, perhaps there's other things it could do > later). > > Or, the splash is all the user starts, and the splash then > immeadiately starts the main, which then uses PatRat's IPC to kill > the splash (once the main is actually running) and come to > foreground (or not). > > Either way, you can change the splash or the code and not affect > the other. > > Kat > > Hi Kat, Yes, that is a very good idea :) I could add a 'shut down' function (easy) to my Display Server so after the main program actually starts it's sends the message for the Display Server to shut down. Only thing is though, the Display Server would have to be able to copy the main programs windows and stuff that the user normally sees when the program starts up. See, there is a second or two after a program starts where the user is just sitting there looking at his/her program, where it doesnt actually need to do anything much except show the data from the previous session. In particular, i have a Checking Account Manager in mind, where the data the comes up initially is the accounts or the check data that has been previously stored in a file data base. On the other hand, i guess it would be simpler to just bind the program, but i wanted to get away from that because i like running many of my programs in .exw mode. Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
9. Re: Interpreter startup speed
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 20, 2006
- 654 views
On Sat, 19 Aug 2006 12:57:13 -0700, Al Getz <guest at RapidEuphoria.com> wrote: >That's not exactly true unless you assume you HAVE to use that >lib for the startup screen too. Also, if you put the link >for CreateWindowEx() near the start of the file it would be >available to the 'run' thread very quickly. True, you'd need to have a specialised/small 'flash' lib that has a message loop etc that is shut before starting the win32lib one.. BUT... that was the point of my message. Pete
10. Re: Interpreter startup speed
- Posted by Craig Welch <euphoria at cwelch.org> Aug 20, 2006
- 688 views
Al Getz wrote: > I could add a 'shut down' function (easy) to my Display Server > so after the main program actually starts it's sends the message > for the Display Server to shut down. Hi Al, That reminds me that late last year you said: "You're right in that those updates would be a nice improvement... especially scrolling...which i needed myself too. I'll have to get back to this and at least add that functionality very soon. I don't think colors will be too hard to add, but pretty printing should already be supported via my own pretty printing routines found in the archive". Any progress on the scrolling and colours? -- Craig
11. Re: Interpreter startup speed
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 20, 2006
- 704 views
On Sat, 19 Aug 2006 16:10:58 -0700, Al Getz <guest at RapidEuphoria.com> wrote: >Kat wrote: >> Hey, Al, i have a silly suggestion: ) >Yes, that is a very good idea :) Yeah, (sarcasm, btw) so you release your new program, but it needs display server to be installed and running first? Why not just bind it and the problem goes away? >On the other hand, i guess it would be simpler to just bind the >program, but i wanted to get away from that because i like running >many of my programs in .exw mode. Oh, you thought of that already, now I'm lost. What you are saying is that _you_ want a splash screen for _your_ program when _you_ already know it will _still_ take 30s to load? Why? Confused, Pete
12. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 20, 2006
- 698 views
Pete Lomax wrote: > On Sat, 19 Aug 2006 16:10:58 -0700, Al Getz wrote: > >> Kat wrote: >>> Hey, Al, i have a silly suggestion: > > ) > >> Yes, that is a very good idea :) > > Yeah, (sarcasm, btw) so you release your new program, but it needs > display server to be installed and running first? Why not just bind it > and the problem goes away? > >> On the other hand, i guess it would be simpler to just bind the >> program, but i wanted to get away from that because i like running >> many of my programs in .exw mode. Then using Eu 2.4 should be fine, or including shrouded libraries in the main program (which might be written in Eu 2.5), or using libraries that previously have been compiled to DLLs or SOs. > Oh, you thought of that already, now I'm lost. What you are saying is > that _you_ want a splash screen for _your_ program when _you_ already > know it will _still_ take 30s to load? Why? > > Confused, > Pete I'm happy that I'm not the only one who is confused here. Al, some possibilities to reduce startup time have already been mentioned, but it seems that you don't want to use any of them. My first impression was, that you wanted to make an omelette without breaking eggs -- now it almost looks to me as if you want to break eggs without making an omelette. Regards, Juergen -- Please excuse my flawed English. My native language is Euphoria.
13. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 20, 2006
- 718 views
Craig Welch wrote: > > Al Getz wrote: > > > I could add a 'shut down' function (easy) to my Display Server > > so after the main program actually starts it's sends the message > > for the Display Server to shut down. > > Hi Al, > > That reminds me that late last year you said: > > "You're right in that those updates would be a nice improvement... > especially scrolling...which i needed myself too. I'll have to > get back to this and at least add that functionality very soon. > I don't think colors will be too hard to add, but pretty printing > should already be supported via my own pretty printing routines > found in the archive". > > Any progress on the scrolling and colours? > > -- > Craig > > Hi Craig, I havent been working on it because i have been working on other things as well as trying to learn a new language (world language, that is, he he). Maybe i need to get back to this however :) Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
14. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 20, 2006
- 685 views
Juergen Luethje wrote: > > Pete Lomax wrote: > > > On Sat, 19 Aug 2006 16:10:58 -0700, Al Getz wrote: > > > >> Kat wrote: > >>> Hey, Al, i have a silly suggestion: > > > > ) > > > >> Yes, that is a very good idea :) > > > > Yeah, (sarcasm, btw) so you release your new program, but it needs > > display server to be installed and running first? Why not just bind it > > and the problem goes away? > > > >> On the other hand, i guess it would be simpler to just bind the > >> program, but i wanted to get away from that because i like running > >> many of my programs in .exw mode. > > Then using Eu 2.4 should be fine, or including shrouded libraries in the > main program (which might be written in Eu 2.5), or using libraries that > previously have been compiled to DLLs or SOs. > > > Oh, you thought of that already, now I'm lost. What you are saying is > > that _you_ want a splash screen for _your_ program when _you_ already > > know it will _still_ take 30s to load? Why? > > > > Confused, > > Pete > > I'm happy that I'm not the only one who is confused here. > Al, some possibilities to reduce startup time have already been > mentioned, but it seems that you don't want to use any of them. > My first impression was, that you wanted to make an omelette without > breaking eggs -- now it almost looks to me as if you want to break eggs > without making an omelette. > > Regards, > Juergen > > -- > Please excuse my flawed English. My native language is Euphoria. Hi Juergen, No, i guess what i want is 2.5 to be as fast as 2.4 for loading. Period. Did i break any eggs this time? hee hee I'm gettin hungry anyway as it's breakfast time in this part of the world :) Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
15. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 20, 2006
- 697 views
Pete Lomax wrote: > > On Sat, 19 Aug 2006 16:10:58 -0700, Al Getz <guest at RapidEuphoria.com> > wrote: > > >Kat wrote: > >> Hey, Al, i have a silly suggestion: > ) > >Yes, that is a very good idea :) > Yeah, (sarcasm, btw) so you release your new program, but it needs > display server to be installed and running first? Why not just bind it > and the problem goes away? > >On the other hand, i guess it would be simpler to just bind the > >program, but i wanted to get away from that because i like running > >many of my programs in .exw mode. > Oh, you thought of that already, now I'm lost. What you are saying is > that _you_ want a splash screen for _your_ program when _you_ already > know it will _still_ take 30s to load? Why? > > Confused, > Pete > > Pete, first lets clear up a few things... First, having a splash screen only helps pretty much when the program will be in the hands of other users and you dont want then sitting there wondering where the heck the program is after they have d clicked the icon. This means the splash screen is only going to be just so useful anyway, but at least it would be something. On the other hand, if 2.5 was as fast as 2.4 for loading nobody would have anything to talk about would they? Let me restate the problems... v2.4 loads .exw based programs fairly quick. v2.5 doesnt. Adding a splash screen helps to some degree. Being able to show the data in the appropriate windows until the program totally loads would be nice, but hard to do, unless it was built into the interp. where another thread could do some of the work. The dual threaded idea wasnt that bad because it would look like v2.4 pretty much (note you DO NOT have to have a message loop to display a window for a few seconds that the user can look at while the program loads completely). I dont see any of this happening anyway so it's probably pointless to talk about it ha ha, unless of course our discussion leads to something useful that Rob likes too he he. Does this make sense now? Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
16. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 20, 2006
- 684 views
Al Getz wrote: > Pete Lomax wrote: > >> On Sat, 19 Aug 2006 16:10:58 -0700, Al Getz wrote: >> >> >Kat wrote: >> >> Hey, Al, i have a silly suggestion: >> ) >> >Yes, that is a very good idea :) >> Yeah, (sarcasm, btw) so you release your new program, but it needs >> display server to be installed and running first? Why not just bind it >> and the problem goes away? >> >On the other hand, i guess it would be simpler to just bind the >> >program, but i wanted to get away from that because i like running >> >many of my programs in .exw mode. >> Oh, you thought of that already, now I'm lost. What you are saying is >> that _you_ want a splash screen for _your_ program when _you_ already >> know it will _still_ take 30s to load? Why? >> >> Confused, >> Pete > > Pete, first lets clear up a few things... > First, having a splash screen only helps pretty much when the > program will be in the hands of other users and you dont want then > sitting there wondering where the heck the program is after they > have d clicked the icon. This means the splash screen is only > going to be just so useful anyway, but at least it would be something. The users would highly prefer an increase of startup speed rather than having an indicator of an unnecessarily slow startup speed. Possibilities for increasing startup speed have been shown to you, but you've rejected them all. > On the other hand, if 2.5 was as fast as 2.4 for loading nobody > would have anything to talk about would they? If, if, ... If my grandmother had a moustache, she would be my grand_father_. <snip> Regards, Juergen -- Please excuse my flawed English. My native language is Euphoria.
17. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 20, 2006
- 701 views
Al Getz wrote: > Juergen Luethje wrote: > >> Pete Lomax wrote: >> >>> On Sat, 19 Aug 2006 16:10:58 -0700, Al Getz wrote: >>> >>>> Kat wrote: >>>>> Hey, Al, i have a silly suggestion: >>> >>> ) >>> >>>> Yes, that is a very good idea :) >>> >>> Yeah, (sarcasm, btw) so you release your new program, but it needs >>> display server to be installed and running first? Why not just bind it >>> and the problem goes away? >>> >>>> On the other hand, i guess it would be simpler to just bind the >>>> program, but i wanted to get away from that because i like running >>>> many of my programs in .exw mode. >> >> Then using Eu 2.4 should be fine, or including shrouded libraries in the >> main program (which might be written in Eu 2.5), or using libraries that >> previously have been compiled to DLLs or SOs. >> >>> Oh, you thought of that already, now I'm lost. What you are saying is >>> that _you_ want a splash screen for _your_ program when _you_ already >>> know it will _still_ take 30s to load? Why? >>> >>> Confused, >>> Pete >> >> I'm happy that I'm not the only one who is confused here. >> Al, some possibilities to reduce startup time have already been >> mentioned, but it seems that you don't want to use any of them. >> My first impression was, that you wanted to make an omelette without >> breaking eggs -- now it almost looks to me as if you want to break eggs >> without making an omelette. > > > Hi Juergen, > > No, i guess what i want is 2.5 to be as fast as 2.4 for loading. > Period. That's what I meant by: "to make an omelette without breaking eggs". Something that is impossible. > Did i break any eggs this time? hee hee I'm gettin hungry > anyway as it's breakfast time in this part of the world :) Enjoy your meal! With "to break eggs without making an omelette", I meant in this context that it looks as if you are willing to put considerable efforts into creating a startup screen etc..., but without achieving the actually desired aim: an increase of startup speed (the "omelette"). Regards, Juergen -- Please excuse my flawed English. My native language is Euphoria.
18. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 20, 2006
- 686 views
- Last edited Aug 21, 2006
Juergen Luethje wrote: > > Al Getz wrote: > > > Juergen Luethje wrote: > > > >> Pete Lomax wrote: > >> > >>> On Sat, 19 Aug 2006 16:10:58 -0700, Al Getz wrote: > >>> > >>>> Kat wrote: > >>>>> Hey, Al, i have a silly suggestion: > >>> > >>> ) > >>> > >>>> Yes, that is a very good idea :) > >>> > >>> Yeah, (sarcasm, btw) so you release your new program, but it needs > >>> display server to be installed and running first? Why not just bind it > >>> and the problem goes away? > >>> > >>>> On the other hand, i guess it would be simpler to just bind the > >>>> program, but i wanted to get away from that because i like running > >>>> many of my programs in .exw mode. > >> > >> Then using Eu 2.4 should be fine, or including shrouded libraries in the > >> main program (which might be written in Eu 2.5), or using libraries that > >> previously have been compiled to DLLs or SOs. > >> > >>> Oh, you thought of that already, now I'm lost. What you are saying is > >>> that _you_ want a splash screen for _your_ program when _you_ already > >>> know it will _still_ take 30s to load? Why? > >>> > >>> Confused, > >>> Pete > >> > >> I'm happy that I'm not the only one who is confused here. > >> Al, some possibilities to reduce startup time have already been > >> mentioned, but it seems that you don't want to use any of them. > >> My first impression was, that you wanted to make an omelette without > >> breaking eggs -- now it almost looks to me as if you want to break eggs > >> without making an omelette. > > > > > > Hi Juergen, > > > > No, i guess what i want is 2.5 to be as fast as 2.4 for loading. > > Period. > > That's what I meant by: "to make an omelette without breaking eggs". > Something that is impossible. > > > Did i break any eggs this time? hee hee I'm gettin hungry > > anyway as it's breakfast time in this part of the world :) > > Enjoy your meal! > > With "to break eggs without making an omelette", I meant in this context that > it looks as if you are willing to put considerable efforts into creating > a startup screen etc..., but without achieving the actually desired aim: > an increase of startup speed (the "omelette"). > > Regards, > Juergen > > -- > Please excuse my flawed English. My native language is Euphoria. Hi Juergen, Oh ok sure. After talking about it here for a while i see what you mean, and also that if multi threads were used to help the startup, the lib would have to be written with the most important functions first (CreateWindow() and others first). See, as it is now, i have a computer that used to open programs just find, until 2.5 came along. Since then, i have also aquired another computer of approximately the same speed (slightly but insignificantly faster). What am i supposed to do, chuck both computers just so i can have faster startup with .exw files? All my other programs run acceptably fast enough, including Watcom. Thus, i was looking for a solution that would allow loading the .exw files faster. Shrouding might help, but then when i edit a program i have to shroud the file before i can run it again right? Not too much difference from binding the whole thing. I'll give it some more thought. Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
19. Re: Interpreter startup speed
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 20, 2006
- 701 views
- Last edited Aug 21, 2006
Just to get a few facts right... 2.4 and 2.5 are about the same when it comes to "loading" time. The difference is that 2.4 can begin executing programs before they are fully loaded whereas 2.5 does not start to execute them until they are fully loaded. Furthermore, it seems that this is only a problem with old PCs that are running programs with huge libraries, such as win32lib. If you cannot/will not change PCs then the use of huge libraries needs to change. For example, if Win32lib was a DLL then it would be pre-loaded and compiled rather than interpreted. Then your small programs (< 20,000 lines) that use the library will not have such an apparent slow start-up time. So maybe we should look at getting huge libraries to be DLLs rather than modify the interpreter, as that would seem to have the biggest bang for the buck. I'm sure that the interpreter can be improved but at best that might give you 10% better start-up times, but a DLL for Win32lib would give many factors of improvement. I vaguely remember that someone had does this but I'm not sure of the current state of play. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
20. Re: Interpreter startup speed
- Posted by Kenneth Rhodes <ken_rhodes30436 at yahoo.com> Aug 21, 2006
- 683 views
Derek Parnell wrote: > > > So maybe we should look at getting huge libraries to be DLLs rather than > modify > the interpreter, as that would seem to have the biggest bang for the buck. I'm > sure that the interpreter can be improved but at best that might give you 10% > better start-up times, but a DLL for Win32lib would give many factors of > improvement. > > I vaguely remember that someone had does this but I'm not sure of the current > state of play. > Logan Kodysz's Win32lib dll example: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=win32+dll > > -- > Derek Parnell > Melbourne, Australia > Skype name: derek.j.parnell Ken Rhodes Folding at Home: http://folding.stanford.edu/ 100% MicroSoft Free SuSE Linux 10.0 No AdWare, SpyWare, or Viruses! Life is Good,
21. Re: Interpreter startup speed
- Posted by "Greg Haberek" <ghaberek at gmail.com> Aug 21, 2006
- 686 views
> So maybe we should look at getting huge libraries to be DLLs rather than > modify the interpreter, as that would seem to have the biggest bang for the buck. > I'm sure that the interpreter can be improved but at best that might give you 10% > better start-up times, but a DLL for Win32lib would give many factors of > improvement. I agree entirely. I don't understand why Rob doesn't have the Translator kick out a wrapper file when it creates a DLL. Every C DLL comes with a header file, right? Why can't a Euphoria DLL come with a corresponding .ew (or .eh) file? I had gotten a decent wrapper going from the 2.5 Source, but I ran into a road block on constants whose values were give by a function. Instead of "constant X = something()" I ended up with "constant X = 5" but that seems to defeat the purpos of having it hard-coded, since it is supposed to run at startup.
22. Re: Interpreter startup speed
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 21, 2006
- 752 views
On Sun, 20 Aug 2006 16:59:39 -0700, Derek Parnell <guest at RapidEuphoria.com> wrote: >Just to get a few facts right... Just to correct you then... (As per my previous post I have no beef with the changes made to 2.5.) > >2.4 and 2.5 are about the same when it comes to "loading" time. The >difference is that 2.4 can begin executing programs before they are >fully loaded whereas 2.5 does not start to execute them until they are >fully loaded. That is simply wrong. As an example, CenterIt.exw takes around 5-8 seconds to load on 2.4 (on this rubbish box), but 25-40 seconds on 2.5. I assume you will agree that program is fully compiled before anything is displayed. I cannot believe any difference would be anything but compilation. I will agree that the additional actual elapsed time for compiling under 2.5 on even a half-decent/recent box is utterly insignificant, /*/what I cannot agree with/*/ is the "fully loaded before execution starts" having anything relevant to do with it. That whole idea is just a red herring, imo - And I have a slow enuf pc to prove it ) >only a problem with old PCs Agreed. >if Win32lib was a DLL Yep, would solve for anyone adamant they must have 2.5 on old kit. As an aside, I would like to try C# / .Net / Mono on this box, just for a look see, but it just ain't never gona take it ) Regards, Pete
23. Re: Interpreter startup speed
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 21, 2006
- 709 views
Pete Lomax wrote: > > On Sun, 20 Aug 2006 16:59:39 -0700, Derek Parnell > <guest at RapidEuphoria.com> wrote: > > >Just to get a few facts right... > Just to correct you then... > (As per my previous post I have no beef with the changes made to 2.5.) > > > >2.4 and 2.5 are about the same when it comes to "loading" time. The > >difference is that 2.4 can begin executing programs before they are > >fully loaded whereas 2.5 does not start to execute them until they are > >fully loaded. > That is simply wrong. As an example, CenterIt.exw takes around 5-8 > seconds to load on 2.4 (on this rubbish box), but 25-40 seconds on > 2.5. I assume you will agree that program is fully compiled before > anything is displayed. I cannot believe any difference would be > anything but compilation. I guess only Big Brother (a.k.a Robert Craig) can resolve this one. I was just going on what I thought he was saying about how 2.5 parses the whole file prior to starting but 2.4 didn't. > I will agree that the additional actual elapsed time for compiling > under 2.5 on even a half-decent/recent box is utterly insignificant, > /*/what I cannot agree with/*/ is the "fully loaded before execution > starts" having anything relevant to do with it. That whole idea is > just a red herring, imo - And I have a slow enuf pc to prove it ) I tried to test this but the newer win32lib doesn't do 2.4 anymore. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
24. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 21, 2006
- 675 views
Al Getz wrote: [snipped old text] > See, as it is now, i have a computer that used to open programs > just find, until 2.5 came along. Since then, i have also aquired > another computer of approximately the same speed (slightly but > insignificantly faster). What am i supposed to do, chuck both > computers just so i can have faster startup with .exw files? > All my other programs run acceptably fast enough, including Watcom. > Thus, i was looking for a solution that would allow loading > the .exw files faster. Shrouding might help, but then when i edit > a program i have to shroud the file before i can run it again right? > Not too much difference from binding the whole thing. > > I'll give it some more thought. You'll only have to shroud again the file that you edited. So in my opinion it's mainly a question of good modularisation of the code (i.e. splitting the code into several include files), which is useful anyway. For instance, my private "mem.e" library has not changed since 2005-11-30. And please think of all those libraries from the Euphoria archieves. I believe most people just _use_ them, and have no need to edit them. So these libraries could be shrouded -- or even could be ccompiled to DLLs/SOs in many cases (although this might be overkill for small libraries). Regards, Juergen -- Please excuse my flawed English. My native language is Euphoria.
25. Re: Interpreter startup speed
- Posted by Ryan W. Johnson <ryanj at fluidae.com> Aug 21, 2006
- 701 views
Derek Parnell wrote: The difference > is that 2.4 can begin executing programs before they are fully loaded whereas > 2.5 does not start to execute them until they are fully loaded. Even in 2.4, the entire win32lib has to be loaded and parsed before you'll ever see anything on the screen anyway, because the first "createWindow" comes after "include win32lib.ew", and besides, the winMain() call is the very last statement in the program. ~Ryan W. Johnson Fluid Application Environment http://www.fluidae.com/ [cool quote here, if i ever think of one...]
26. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 21, 2006
- 701 views
- Last edited Aug 22, 2006
Derek Parnell wrote: > > Just to get a few facts right... > > 2.4 and 2.5 are about the same when it comes to "loading" time. The difference > is that 2.4 can begin executing programs before they are fully loaded whereas > 2.5 does not start to execute them until they are fully loaded. > > Furthermore, it seems that this is only a problem with old PCs that are > running > programs with huge libraries, such as win32lib. If you cannot/will not change > PCs then the use of huge libraries needs to change. For example, if Win32lib > was a DLL then it would be pre-loaded and compiled rather than interpreted. > Then your small programs (< 20,000 lines) that use the library will not have > such an apparent slow start-up time. > > So maybe we should look at getting huge libraries to be DLLs rather than > modify > the interpreter, as that would seem to have the biggest bang for the buck. I'm > sure that the interpreter can be improved but at best that might give you 10% > better start-up times, but a DLL for Win32lib would give many factors of > improvement. > > I vaguely remember that someone had does this but I'm not sure of the current > state of play. > > > -- > Derek Parnell > Melbourne, Australia > Skype name: derek.j.parnell Hi there Derek, Yes i agree pretty much. Im just starting to think about this again too. One thing i was wondering though, is that at some point i remember you saying you were working on a Euphoria clone right? Are you still working on that and if so, when will you have something ready? I would be interested in something that would load .exw files fast. Not too interested in Binding, and i feel that should be left to RDS anyway. Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
27. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 21, 2006
- 699 views
- Last edited Aug 22, 2006
Juergen Luethje wrote: > > Al Getz wrote: > > [snipped old text] > > > See, as it is now, i have a computer that used to open programs > > just find, until 2.5 came along. Since then, i have also aquired > > another computer of approximately the same speed (slightly but > > insignificantly faster). What am i supposed to do, chuck both > > computers just so i can have faster startup with .exw files? > > All my other programs run acceptably fast enough, including Watcom. > > Thus, i was looking for a solution that would allow loading > > the .exw files faster. Shrouding might help, but then when i edit > > a program i have to shroud the file before i can run it again right? > > Not too much difference from binding the whole thing. > > > > I'll give it some more thought. > > You'll only have to shroud again the file that you edited. So in my > opinion it's mainly a question of good modularisation of the code > (i.e. splitting the code into several include files), which is useful > anyway. > For instance, my private "mem.e" library has not changed since > 2005-11-30. And please think of all those libraries from the Euphoria > archieves. I believe most people just _use_ them, and have no need to > edit them. So these libraries could be shrouded -- or even could be > ccompiled to DLLs/SOs in many cases (although this might be overkill > for small libraries). > > Regards, > Juergen > > -- > Please excuse my flawed English. My native language is Euphoria. Hi again, Ok, so you are saying shroud with v2.4 and run with v2.5? If this works and is fast yes i might be able to rig something up to quickly shroud my file after an edit. Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
28. Re: Interpreter startup speed
- Posted by Al Getz <Xaxo at aol.com> Aug 21, 2006
- 716 views
- Last edited Aug 22, 2006
Ryan W. Johnson wrote: > > Derek Parnell wrote: > The difference > > > is that 2.4 can begin executing programs before they are fully loaded > > whereas > > 2.5 does not start to execute them until they are fully loaded. > > Even in 2.4, the entire win32lib has to be loaded and parsed before you'll > ever > see anything on the screen anyway, because the first "createWindow" comes > after > "include win32lib.ew", and besides, the winMain() call is the very last > statement > in the program. > > ~Ryan W. Johnson > > Fluid Application Environment > <a href="http://www.fluidae.com/">http://www.fluidae.com/</a> > > [cool quote here, if i ever think of one...] Hi there, Well 2.4 does it faster that's all i know :) Also, it's still nice to see a window up on screen while the rest of the program loads. Note that winmain() doesnt really have to be the last line of the file, it's just the way most people write their programs. I guess all this still deserves much more thought anyway though. Take care, Al E boa sorte com sua programacao Euphoria! My bumper sticker: "I brake for LED's" From "Black Knight": "I can live with losing the good fight, but i can not live without fighting it". "Well on second thought, maybe not."
29. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 22, 2006
- 677 views
Al Getz wrote: > Juergen Luethje wrote: >> >> Al Getz wrote: >> >> [snipped old text] >> >>> See, as it is now, i have a computer that used to open programs >>> just find, until 2.5 came along. Since then, i have also aquired >>> another computer of approximately the same speed (slightly but >>> insignificantly faster). What am i supposed to do, chuck both >>> computers just so i can have faster startup with .exw files? >>> All my other programs run acceptably fast enough, including Watcom. >>> Thus, i was looking for a solution that would allow loading >>> the .exw files faster. Shrouding might help, but then when i edit >>> a program i have to shroud the file before i can run it again right? >>> Not too much difference from binding the whole thing. >>> >>> I'll give it some more thought. >> >> You'll only have to shroud again the file that you edited. So in my >> opinion it's mainly a question of good modularisation of the code >> (i.e. splitting the code into several include files), which is useful >> anyway. >> For instance, my private "mem.e" library has not changed since >> 2005-11-30. And please think of all those libraries from the Euphoria >> archieves. I believe most people just _use_ them, and have no need to >> edit them. So these libraries could be shrouded -- or even could be >> ccompiled to DLLs/SOs in many cases (although this might be overkill >> for small libraries). > > Ok, so you are saying shroud with v2.4 and run with v2.5? > If this works and is fast yes i might be able to rig something up > to quickly shroud my file after an edit. Yes, files that are shrouded with Eu 2.4 can be included in an Eu 2.5 program. This is especially useful for large files that do not change too often. You don't have to re-shroud them when you edit your main program. Try it. Regards, Juergen
30. Re: Interpreter startup speed
- Posted by Bernie Ryan <xotron at bluefrog.com> Aug 22, 2006
- 679 views
- Last edited Aug 23, 2006
Juergen Luethje wrote: > Yes, files that are shrouded with Eu 2.4 can be included in an Eu 2.5 > program. This is especially useful for large files that do not change > too often. You don't have to re-shroud them when you edit your main > program. Try it. > Juergen: Now you guys understand why I have been asking Rob to add shrouding to generate IL code output that could be included when using ver 3.0 That way include files could be precompiled. This would solve the speed of loading. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
31. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 23, 2006
- 664 views
Bernie Ryan wrote: > Juergen Luethje wrote: > >> Yes, files that are shrouded with Eu 2.4 can be included in an Eu 2.5 >> program. This is especially useful for large files that do not change >> too often. You don't have to re-shroud them when you edit your main >> program. Try it. > > Juergen: > > Now you guys understand why I have been asking Rob > to add shrouding to generate IL code output that > could be included when using ver 3.0 > > That way include files could be precompiled. > This would solve the speed of loading. Yes, I do. I have asked for that myself in the past for the samre reason. Several years ago, before I learned to know Euphoria, I've already used precompiled modules with PowerBASIC for DOS (with PB, the module files were precompiled to machine code). Regards, Juergen -- Please excuse my flawed English. My native language is Euphoria.
32. Re: Interpreter startup speed
- Posted by Jason Gade <jaygade at yahoo.com> Aug 23, 2006
- 695 views
Juergen Luethje wrote: > > Bernie Ryan wrote: > > > Juergen Luethje wrote: > > > >> Yes, files that are shrouded with Eu 2.4 can be included in an Eu 2.5 > >> program. This is especially useful for large files that do not change > >> too often. You don't have to re-shroud them when you edit your main > >> program. Try it. > > > > Juergen: > > > > Now you guys understand why I have been asking Rob > > to add shrouding to generate IL code output that > > could be included when using ver 3.0 > > > > That way include files could be precompiled. > > This would solve the speed of loading. > > Yes, I do. I have asked for that myself in the past for the samre reason. > Several years ago, before I learned to know Euphoria, I've already used > precompiled modules with PowerBASIC for DOS (with PB, the module files were > precompiled to machine code). > > Regards, > Juergen > > -- > Please excuse my flawed English. My native language is Euphoria. I think Rob had reasons for not doing this, but if he can do it from 2.4 to 2.5 I see no reason not to do it in 3.0. I have never registered despite being a Euphoria follower for about ten years now. A feature like this would certainly be a value-add for this language. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
33. Re: Interpreter startup speed
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Aug 25, 2006
- 687 views
Juergen Luethje wrote: > > > I'm happy that I'm not the only one who is confused here. > Al, some possibilities to reduce startup time have already been > mentioned, but it seems that you don't want to use any of them. > My first impression was, that you wanted to make an omelette without > breaking eggs -- now it almost looks to me as if you want to break eggs > without making an omelette. > Juergen, I'm amazed that you continue to reply to Al. Why do you bang your head against the wall? He commonly asks dumb questions, and refuses to listen to the answers. I typically refuse to even read posts that he writes any more. I'm sorry, Al, but it often seems like you don't ever think about what you post, and that you don't understand the answers you get. If you didn't submit contributions, I'd wonder if you weren't really trolling this forum. Seriously. Matt Lewis
34. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 25, 2006
- 672 views
Jason Gade wrote: > Juergen Luethje wrote: > > > > Bernie Ryan wrote: > > > > > Juergen Luethje wrote: > > > > > >> Yes, files that are shrouded with Eu 2.4 can be included in an Eu 2.5 > > >> program. This is especially useful for large files that do not change > > >> too often. You don't have to re-shroud them when you edit your main > > >> program. Try it. > > > > > > Juergen: > > > > > > Now you guys understand why I have been asking Rob > > > to add shrouding to generate IL code output that > > > could be included when using ver 3.0 > > > > > > That way include files could be precompiled. > > > This would solve the speed of loading. > > > > Yes, I do. I have asked for that myself in the past for the samre reason. > > > > Several years ago, before I learned to know Euphoria, I've already used > > precompiled modules with PowerBASIC for DOS (with PB, the module files were > > precompiled to machine code). > > > > Regards, > > Juergen > > I think Rob had reasons for not doing this, but if he can do it from 2.4 to > 2.5 I see no reason not to do it in 3.0. > > I have never registered despite being a Euphoria follower for about ten years > now. A feature like this would certainly be a value-add for this language. I hope Rob will "read the signs". Regards, Juergen
35. Re: Interpreter startup speed
- Posted by Juergen Luethje <j.lue at gmx.de> Aug 26, 2006
- 672 views
Juergen Luethje wrote: > I think we should go back to discussion about Euphoria programming. > And please, Al and all ( pun intended ), please don't write things > like "Matt you dingbat" _in the subject_ (with or w/o smiley). Please ... > That does actually not correspond to the netiquette. > > Have a nice weeekend everybody! > > Juergen Whoops ... In my previous post, I had forgotten to remove that stuff from the subject myself, I'm sorry. Regards, Juergen