Re: Euphoria dlls with multitasking
- Posted by mattlewis (admin) Oct 03, 2009
- 1741 views
Question: why does the front end "cheat"? Does that not make it a bit slower? I have noticed pretty long load times for even simple Euphoria programs anymore.
"Cheat" is maybe the wrong word. Obviously, the front end is translated euphoria code. If you look at the source code for euphoria, in be_execute.c, there is a giant switch statement that is the heart of running interpreted code. It does an awful lot of stuff in there.
However, there is a lot of other stuff that is done via function calls, like opening a file, any IO, copying a sequence for a copy on write operation, etc. These other functions are also used by the translator, though there are some differences, especially for certain things like tasks. Others are identical, such as copying a sequence, since a sequence is a sequence is a sequence.
In any case, the front end for the interpreter uses the same runtime functions that your interpreted code uses. And again, for most things, this is fine, because there really is no difference. As we've expanded the front end, there have been some places where we've changed the runtime to handle translated code slightly differently, meaning that the translated C code might call a similar, but different function than interpreted code does.
Without knowing anything about the programs you're talking about, it's hard to say why they load slower. We've had a couple of releases with memory leaks (there aren't any known memory leaks right now) that slowed things down quite a bit.
Another gotcha has to do with global symbols in files that aren't directly included. This relates to the new feature that allows forward referencing, and also the improved method for resolving symbols and avoiding namespace conflicts. It actually simplifies coding, so that two files can rely on each other, and are able to use the full power of each without having to manage carefully which is included first, or moving the location of the include statements in each file, or requiring routine id and call_proc/func.
The problem arises when you use a library that declares lots of global symbols. Of course, this was the only way to write a library pre-4.0. But the real issues occur when you have source files that don't include the library. This is very common in win32lib apps (and, in fact, the IDE is probably one of the worst). Basically, the main file includes win32lib, and then includes lots of other application modules. Each of those modules uses stuff in win32lib, but never includes win32lib.
By simply adding "include win32lib.ew" to the top of each file, the parsing will speed up a lot. Plus, less memory will be used during parsing. I could talk a lot more about this, but that's enough for one post.
Matt
tl;dr The front end is a special case of translated code, and in 4.0, always include libraries that you use in each file.
