On Saturday, Mar 22, 2003, at 13:10 Asia/Tokyo, Chris Nandor wrote:
So I have this problem: Mac::Carbon takes a long time to load.
$ time perl -Iblib/arch -Iblib/lib -MMac::Carbon -e1
real 0m2.923s user 0m2.570s sys 0m0.160s
Profiling the run showed that over 80% of that time is taken by dyld, so I
wondered if prebinding could solve the problem. However, perl uses .bundle
files for DynaLoader, and .bundle files cannot be prebound.
Drat.
Does your /var/log/system.log say something like the following?
Mar 23 04:51:05 dan-pbg4 /usr/libexec/fix_prebinding: /usr/local/bin/perl couldn't be prebound in the past, and probably can't be prebound now.
Mar 23 04:51:05 dan-pbg4 /usr/libexec/fix_prebinding: 2003-03-23 04:51:05 +0900: prebinding for perl done.
If so, try
sudo update_prebinding -force -root /
This AT LEAST makes that system warning go away and perl launches faster (sometimes significantly, sometime just slightly). At least it saves disk access by reducing the need to log the warnings.
You may know that Apple's Software Updates does this update_prebinding but without -force and without it that syslog warnings will not go away. Drat.
And I am not sure how much time you can save by converting .bundle to .dylib
man fix_prebinding
These hints are used by the dynamic loader to launch processes prebound,
eliminating the need to look up dynamically linked symbols. If these
hints are out-of-date, the dynamic linker instead must lookup referenced
symbols. As a result, the application may launch from 10-30% slower.
10-30% seems a lot but that still does not explain the time it takes to load your module. I've tested a few biggies but even such big modules as Encode::JP and POSIX take less than 0.1s to load on my TiBook (800MHz). It seems that the size of module does not matter much. Maybe the number of symbols therein?
IMHO, there is a good reason why Wilfredo Sanchez chose not to prebind XS
http://developer.apple.com/tools/projectbuilder/Prebinding.html
Requirements for Prebinding
To work properly, libraries and executables must meet several important requirements:
1. Libraries must not have overlapping preferred addresses. For each release of Mac OS X the Apple-supplied libraries are all prebound and do not have overlapping addresses. Your libraries must not overlap with any of your own libraries, and also must not overlap with any of the Apple-supplied libraries that are installed with Mac OS X. There is currently no way to automatically select an address for a library to ensure that it does not overlap the addresses of other libraries. Non-Apple libraries can use any address in the range 0x00000000to 0x3FFFFFFF. For the Mac OS X 10.0 release, all addresses above 0x90000000 are also available. To set the address of a library, pass either the -seg1addr flag or the -seg_addr_table flag to ld(1). All executables should be at the default address, 0x00000000. The default address is 0x00000000. When selecting addresses for libraries, the address range of the largest executable using the libraries should be avoided.
2. There can be no undefined symbols. In most cases, this means that you must link against your dependent libraries. It also means that there can be no circular dependencies (cases where library A calls a function in library B, and a function in library B also calls a function in library A). Circular dependencies can be removed by changing the code to dynamically look up the function instead of directly referencing it.
3. You cannot override symbols that are referenced in flat namespace images used by the dependent libraries. For example, you can't define your own malloc and then prebind using flat namespace libraries.
Simply put, it is just too darn hard to prebind all XS without address overlaps, especially when CPAN modules are concerned. On the other hand, libperl is .dylib already so it may be able to take advantage of prebinding.
You should also note that launching takes much longer when perl is built w/ -DDEBUGGING is on.
Dan the Man with Too Many Files to Prebind
#!/usr/local/bin/perl
