Linked to libc.dylib (which is libSystem.B.dylib under 10.4.5), which
weighs in at 4.3 MB on PPC Macs. This dynamic library has to be
loaded once too, although it is used by many, many processes, so its
footprint can be amortized over many processes.
What is your point? Nobody is saying that C tools are "unfairly
small". Just that your suggestion that the framework has to be loaded
for each command line tool you make with REALbasic is incorrect.
Besides, even if it did have to be loaded separately for each process
invoked, if you're invoking MwRb command line tools a lot in a
production system, the tool binary and the dynamic library will find
their way into the disk cache and the performance hit will be
negligible. That's one reason your assessment isn't just wrong, but
total BS.
And FWIW, the right way to address these kinds of performance
questions is not to sit and theorize based on what you have taught
yourself since you started programming in 1998. It is to build the
damned thing and then figure out if there are performance problems
and identify what they are and what really needs to be done to fix
them. You might end up surprised that someone with formal education
thought about all the issues you bring up and designed to mitigate
them while still retaining the ease of programming console apps in
REALbasic. Who'da thunk?
-Brad
On Feb 20, 2006, at 2:22 PM, Theodore H. Smith wrote:
All the tool needs to tell the OS, is what C function names it
links to, and get the address of them.
Many C shell tools can be made with only using very simple Unix
calls, like fopen or open or malloc.
It doesn't make sense to say that because C tools use malloc and
malloc is provided by the system, that means the C tools are
unfairly small looking.
Because RB uses OS provided calls for pretty much the same things,
anyhow. RB might use NewPtr on Classic, or FSRef functions on
Carbon... so it also should be small, right?
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
