Problem starting POL
Moderator: POL Developer
Re: Problem starting POL
Another way is to create an include file that does only have the "use" entries ( not the npc though ) and including that in every script and never have to worry about the "use" entries anymore
Re: Problem starting POL
But in that way, there is some performance decrement, by having all modules included in a script?
If not, why at all exist modules?
If not, why at all exist modules?
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Re: Problem starting POL
You make a good point Xeon. If you want a particular "include" file to be a collection of general purpose functions that relate to storage but don't want to have to define "use storage;" in every program that may need to use the "storage" include file you would have to have the storage module declared in the include file.xeon wrote:I do not agree with that.CWO wrote:'use' shouldn't be used in includes. Only in sources. It drives me insane to see a 'use x;' in a .inc file.
Suppose your .inc file is a black box. If you don't put "use ..." statements inside it, you have to put them in your .src. And to know which modules you need, your only way is "edit - compile - look which module ecompile states is missing" in a loop.
So to me it makes sense to put "use " statements inside .inc
I have never tried declaring all the modules in a program too see if it adds size to the compiled code but I suppose, without understanding the internals of the POL Core, that would be one way to see if doing that adds any complexity, or performance hit, to your code.But in that way, there is some performance decrement, by having all modules included in a script?
If not, why at all exist modules?
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Re: Problem starting POL
OK. I did a test using the following code. The compiled ECL file was 486 Bytes. I then removed the "use" statements and the resulting file size was 102 Bytes. It appears that the space consumed by having unnecessary "use" statements is minimal. I examined the compiled file in my editor and along with the unreadable binary blobs the names of the modules appeared in plain text. How performance might be affected by the addition of non-essential "use" statements I cannot say.
Code: Select all
use uo;
use os;
use vitals;
use storage;
use polsys;
use math;
use boat;
use attributes;
use cfgfile;
use basic;
use cliloc;
use datafile;
use file;
use http;
use party;
use unicode;
use util;
program uses_test()
endprogram
Re: Problem starting POL
I believe Austin elaborated on this before when they initially branched off uo.em into multiple .em files. I believe it had something to do with making POL faster since it didn't have to search through as many functions to find the specific core function you're running. Although with how powerful computers have gotten nowadays, the benefit may be negligible but I haven't tested this nor heard any results of testing with all use statements in a script.
Re: Problem starting POL
I wonder if bundling all functions in a single em would be substantially slower. I'd probably try to push these to a single hash-map.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Re: Problem starting POL
I am still unclear how the functions in the modules are invoked. Is the necessary code from a module's function included in the compiled *.ecl file or are the parameters passed to the Core at runtime where the compiled C code for that function resides? I always thought it the the former rather than the latter.CWO wrote:I believe Austin elaborated on this before when they initially branched off uo.em into multiple .em files. I believe it had something to do with making POL faster since it didn't have to search through as many functions to find the specific core function you're running. Although with how powerful computers have gotten nowadays, the benefit may be negligible but I haven't tested this nor heard any results of testing with all use statements in a script.
Re: Problem starting POL
em functions are executed by the core thus aren't included into .ecl. I believe core does a map lookup for every call to a module function with a separate map per module. I am not sure if using additonal modules incur any performance penalty. In theory UO.EM has substantially bigger number of functions and is almost always used thus the overhead of using every other module is negligible.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Re: Problem starting POL
Thanks Andenixa.