1. Interpreter startup speed
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
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
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
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
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
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
-
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
-
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
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
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
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
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
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
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
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
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
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
-
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
-
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
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
> 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
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
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
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
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
-
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
-
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
-
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
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
-
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
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
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
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
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
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
