Hi Joe,
Using libdemo.bac and program.bac,
First I put everything in a single program and just called "bla" as normal function. I'll call this the "complete" program.
Code: Select all
FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION
x = 5
result = bla(x)
PRINT result
The binary for this file is 34k (33,982)
Next I IMPORTed the libdemo.so into program.bac
Code: Select all
IMPORT "bla" FROM "libdemo.so" TYPE long
x = 5
result = bla(x)
PRINT result
This gave a file size of 34K (34096), just a few bytes larger than the
"complete" program. Note here that no path is specified to libdemo.so,
which is in /usr/lib. (For ref. "ldd" does not show a link to libdemo)
Then I compiled per above example using bacon -l demo program.bac.
The size is 38k (37,997).
(By the way, BaconGUI also has the option of compiling using linking.)
Next I tried this:
Compiled binary for this is 34k.
Then I "linked" it with a hug.so file and compiled. That gave a binary of 38K.
(It would appear that linking increases the binary size by 4k.)
Then I compiled using INCLUDE "/usr/share/BaCon/hug.bac" . This binary is 177k.
Next I compiled using INCLUDE "/usr/share/BaCon/hug_imports.bac". This
binary is 51K.
If I understand it, linking is a soft link. ie. the lib file needs to exist some
where in the path. While using INCLUDE hard codes the path.
Going by binary size alone, linking has a definite advantage.
But, what about memory usage. Does the whole linked file get loaded into
memory when the program is run; or do modules get loaded as called.
Someone know about this?
Because when hug.bac is INCLUDEd in a program, you have the option
of only loading the modules specifically needed, thereby reducing memory
usage.
Regardless, it would seem to be more appropriate to have libhug.so than
hug.so. Then hug_imports.bac could point to libhug. The uptic being that
either soft or hard linking could be accommodated.
EDIT: See next post about why linking doesn't seem to work for hug.
Well, don't know if that classifies as "re-thinking", or even thinkin', but there you have it.
rod