OCCT3D
DiscussionsIssue archiveOther usage issues

Archived discussion

Size of shared object files

Other usage issuesFri, 04/06/2001 - 18:335 replies

Browse this forum
QuestionAuthor

The size of the shared object files generated by OpenCascade is a problem in at least two regards.

First, for a new platform, the larger the shared object file, the greater the chance of running into bugs in the linking tools on that platform (I have seen link failures for the STEP module under IRIX). A less important part of this issue is that compilation and linking bugs that are encountered in a module require that the expensive linking step be completely redone for each recompile and relink step.

The second problem area has to do with efficiency in the application build with the OpenCascade libraries. If this application uses only a small fraction of the functionality in a module, there is the chance that the dynamic page loading from the shared object file for the module will load mostly unused portions of that library module. If the functions used happen to be widely scattered throughout the shared object file, this problem becomes worse.

Another, less important issue for application developers is the desire to minimize the overall size of the applications that they ship, By breaking the modules into smaller units, the shared object files that actually need to be packaged with the application will use less disk space than the shared object files of the current, large modules.

Of course, the need for smaller modules is most dramatic with the STEP module, but it is also important with the IGES module. At the very least the Reader and Writer portions of STEP and IGES should be placed in separate modules, with common functionality going into yet another module.

Another practical reason for this is the fact that some applications would only need to have a STEP or IGES Reader. Others may only need a STEP or IGES Writer, although this is less likely. Moreover, even for applications that involve both a Reader and Writer of STEP or IGES, these actions would only be performed at widely separated times. Separate shared object libraries would then help the Reader and Writer phases of STEP and IGES to be more efficient.

So the suggestion here is: please break up the large modules of OpenCascade into several submodules in a way that will tend to maximize the efficiency of the shared object files, particularly the loading of pages of these shared object files into memory.

Thanks, Grant Cook

Discussion

5 archived replies

Posts are displayed in their archived order.

01Commenter-1

Well, the reason of that (perhaps not the only one, but surely a strong one) is to have an organisation in modules, as simple as possible. So, many things are gathered, I agree.

Basically, the data exchange functions are very modular. But to provide "easy to link and to use" (and also to manage) modules leads to simplifications. In other words, the various capabilities of, say, IGES, are available in one set, whichever the needed functions (as read / write ..) and scope in the standard (i.e. sets of entity types) are.

Possibilities of reducing embedded functions exist, so recommendations can be done to do so. The additional question is then, how to manage. This question will be set again on future enhancements.

However, I get the idea, to define in a first time some recommendations, then adapting code as needed to have them easier to apply. While to really produce separate modules means to manage them too ... (another possible issue is multiplication of little shared libraries, it is also to be put in balance).

02Commenter-2

I would agree with Grant when he says that the STEP module is unreasonably large. The question of organizing is also valid, but at the point where a module becomes as large as this one, the other considerations should take precedence. There is a balance that needs to be achieved between organizing the libraries in a coherent way, and keeping them small enough to manage.
As of now, many of the limits of operating systems and build tools are pushed by the libraries' size. In my Autoconf port I had to add two new features into GNU Libtool to get around the problems resulting from their large size.
So I vote (if this _is_ a Democracy *smirk*) for breaking TKSTEPStd into two or three consistently organized, smaller libraries.

03Commenter-2

Since there hasn't been a response to this, I have a bit more to add. I don't belive that the current CVS version of Open CASCADE will compile under IRIX. TKSTEPStd is so big that additional compiler options are required to link it, and these aren't in the current CVS compilation scripts. If you doubt this, compile it yourself.

04Commenter-3

It is necessary to change the kernel parameter for max number of arguments from the IRIX default.

The tool to use is systune. The parameter name is ncargs.

05Commenter-2

That is not the problem I've run into, it has to do with the size of the shared object, not the size of the command line. Also, you can't generally change the kernel parameters, as some software will not work under an altered kernel (KTI's ICAD for example www.ktiworld.com).
The right way around the command length limitations is exactly what Matra has done, use a loop to add objects together, then link the consoladated objects. The other option is to use the IRIX linker's -objectlist option.
No the problem that won't allow you to compile is somthing else having to do with the default option "-G8" being too high, "-G4" will work, but if TKSTEPStd wasn't so big, these options wouldn't be necessary. It's just a bad idea in general to push these limits, the more we do, the more problems we run into.