1. Ver 4.0 start up speed.
- Posted by bernie Feb 24, 2009
- 857 views
I thought that the start up time for version 4
was a result of my code not be efficient so I
down-loaded the win32lib and discovered that It
took just as much time to load code using win32lib.
There has be a simple way to tell the parser that
once the bugs are out of BIG libraries/programs NOT
to scan for forward reference and skip parsing STD libraries
just like we can do using 'without type_check' 'without trace'
ETC.
Isn't there anyone out there that is concern about this start speed ?
2. Re: Ver 4.0 start up speed.
- Posted by mattlewis (admin) Feb 24, 2009
- 804 views
There has be a simple way to tell the parser that
once the bugs are out of BIG libraries/programs NOT
to scan for forward reference and skip parsing STD libraries
just like we can do using 'without type_check' 'without trace'
When you find it, please let us know.
I do not think that Win32Lib has yet been updated to have the proper include statements per its usage of library internal symbols. The last time I checked, there were ~6K such references from parsing Win32Lib itself.
The easiest way to speed up the start time of your code is to include the files you need from each file that needs them, and not to rely on global symbols being included by some other file.
Could you please explain why "STD libraries" have been singled out for parsing avoidance? Or even what that means?
Matt
3. Re: Ver 4.0 start up speed.
- Posted by DerekParnell (admin) Feb 24, 2009
- 852 views
I thought that the start up time for version 4 was a result of my code not be efficient so I down-loaded the win32lib and discovered that It took just as much time to load code using win32lib.
The win32lib library has not yet been updated to take advantage of the 4.0 features, so it is still relying on global symbols being present. So it seems that it is still just as efficient as your coding style.
There has be a simple way to tell the parser that once the bugs are out of BIG libraries/programs NOT to scan for forward reference and skip parsing STD libraries just like we can do using 'without type_check' 'without trace' ETC.
I have it on my todo list for win32lib to add the necessary include files to avoid the deferred referencing issue.
A better option for the general case might be to pre-parse files and store them as 'il'-type files which can be directly used by the interpreter instead of the original source files. This concept has yet to be agreed upon by the development team , and I don't know how feasible it might be but on the surface it looks like a good solution to speed up start-up times for interpreted applications.
Isn't there anyone out there that is concern about this start speed ?
I'll assume that this is a rhetorical question and thus ignore it.
4. Re: Ver 4.0 start up speed.
- Posted by bernie Feb 24, 2009
- 854 views
I do not think that Win32Lib has yet been updated to have the proper include statements per its usage of library internal symbols. The last time I checked, there were ~6K such references from parsing Win32Lib itself.
The easiest way to speed up the start time of your code is to include the files you need from each file that needs them, and not to rely on global symbols being included by some other file.
I have no globals only public
I'll look closer at the way things are being included.
Could you please explain why "STD libraries" have been singled out for parsing avoidance? Or even what that means?
Matt
What I mean is; is each std/include file being parsed every time
they are included in a program ? Because they are full of comments
which takes up parse time. Some include files only contain one feature that is necessary for
a program; but the complete file is still parsed.
5. Re: Ver 4.0 start up speed.
- Posted by mattlewis (admin) Feb 24, 2009
- 810 views
A better option for the general case might be to pre-parse files and store them as 'il'-type files which can be directly used by the interpreter instead of the original source files. This concept has yet to be agreed upon by the development team , and I don't know how feasible it might be but on the surface it looks like a good solution to speed up start-up times for interpreted applications.
This is now technically feasible, though there are issues to be addressed. Essentially, this would require the parsing process to be a little more like building a C program. We'd first 'compile' the standard libraries (or whatever), and later link them into an application.
I've put some thought into something similar, which would allow interpreted code to seemlessly use translated code. See the bullet "Compile a euphoria include as a dll."
Matt
6. Re: Ver 4.0 start up speed.
- Posted by mattlewis (admin) Feb 24, 2009
- 864 views
I do not think that Win32Lib has yet been updated to have the proper include statements per its usage of library internal symbols. The last time I checked, there were ~6K such references from parsing Win32Lib itself.
The easiest way to speed up the start time of your code is to include the files you need from each file that needs them, and not to rely on global symbols being included by some other file.
I have no globals only public
I'll look closer at the way things are being included.
Could you please explain why "STD libraries" have been singled out for parsing avoidance? Or even what that means?
Matt
What I mean is; is each std/include file being parsed every time
they are included in a program ? Because they are full of comments
which takes up parse time. Some include files only contain one feature that is necessary for
a program; but the complete file is still parsed.
I wouldn't worry about comments. I ran the following code:
integer fn = open( "bernie.ex", "w" ) constant COMMENT = "-- This is a pretty long comment. There will be many of them. Let's see how long it will take to parse." for i = 1 to 10000 do puts( fn, COMMENT ) end for close(fn)
This created a 1.1M file of comments, and:
$ time exu bernie real 0m0.106s user 0m0.076s sys 0m0.020sMatt
