Very Computer

Platform IBM RS6000, AIX 4.3.3

We are forced by our database vendor to compile our programs with their non
shared libraries (.a) instead of their shared object libraries (.so). This
because the programs did not run anymore with their latest database version
(although they did compile and link). So we compiled our programs with the
non-shared libraries but now we experience serious performance problems due
to increased memory usage. Can anybody tell me something about this subject
or give some suggestions ?

Regards,

Louis Banens

Below are the new compile and link statements, are these optimal/correct for
AIX ?

gcc -DIDI_BIG_ENDIAN -DNOTIMEOUT_SUPPORTED=IDI_TRUE -DOS_SHMADDR_OK=IDI_TRUE
 -DSTRTOUL_SUPPORTED=IDI_TRUE -DUNIX -DSVR4 -DSVR4S -D_REENTRANT -DSTATVFS_S
UPPORTED -DAIO -O -c db_actions.c -DIDI_SERVER  -I/apps/v83/dm/include

gcc -DIDI_BIG_ENDIAN -DNOTIMEOUT_SUPPORTED=IDI_TRUE -DOS_SHMADDR_OK=IDI_TRUE
 -DSTRTOUL_SUPPORTED=IDI_TRUE -DUNIX -DSVR4 -DSVR4S -D_REENTRANT -DSTATVFS_S
UPPORTED -DAIO -s cgi_functions.o fldvalues.o ddb_arrays.o filltempl.o
opi_err.o db_functions.o ddb_functions.o parse_query.o ./db_actions.o
/apps/v83/dm/obj/opilib/opilib.a /apps/v83/dm/obj/opcslib/opcslib.a
/apps/v83/dm/obj/opilib/opilib.a
/apps/v83/dm/obj/opcslib/opcslib.a -L/apps/v83/dm/lib -ldmlib -L/apps/v83/dm
/lib -lsslib -L/apps/v83/dm/lib -luelib -lnsl  -lpthread -lopilib -lm -o
db_actions29236 -DIDI_SERVER  -I/apps/v83/dm/include

Regards,

Louis Banens

Hi,

Platform IBM RS6000, AIX 4.3.3

We are forced by our database vendor to compile our programs with their non
shared libraries (.a) instead of their shared object libraries (.so). This
because the programs did not run anymore with their latest database version
(although they did compile and link). So we compiled our programs with the
non-shared libraries but now we experience serious performance problems due
to increased memory usage. Can anybody tell me something about this subject
or give some suggestions ?

Regards,

Louis Banens

Consider your options for the best choice in your situation.

DaveB

Quote:> Forgotten,

> Below are the new compile and link statements, are these optimal/correct
for
> AIX ?

Quote:>  -DSTRTOUL_SUPPORTED=IDI_TRUE -DUNIX -DSVR4 -DSVR4S -D_REENTRANT -DSTATVFS
_S
> UPPORTED -DAIO -O -c db_actions.c -DIDI_SERVER  -I/apps/v83/dm/include

Quote:>  -DSTRTOUL_SUPPORTED=IDI_TRUE -DUNIX -DSVR4 -DSVR4S -D_REENTRANT -DSTATVFS
_S
> UPPORTED -DAIO -s cgi_functions.o fldvalues.o ddb_arrays.o filltempl.o
> opi_err.o db_functions.o ddb_functions.o parse_query.o ./db_actions.o
> /apps/v83/dm/obj/opilib/opilib.a /apps/v83/dm/obj/opcslib/opcslib.a
> /apps/v83/dm/obj/opilib/opilib.a

--
--Ed Cashin                     integrit file-verification system:

    Note: If you want me to send you email, don't munge your address.

Strange thing is that one running process seems to slow down al other
processes. I cannot imagine that it only has to do with memory. Can it also
have something to do how is dealt with threads ?

By the way, the physical size of the executable (with .a) is smaller than
before compilation (.so). Isn't that strange.

Regards,

Louis Banens

Louis,
    The libraries are either compiled into the executable (.a) or are linked
in at execution (.so).
So, when your DB vendor recommended that you use the non-runtime libraries
you increased the size of your executable because it includes the libraries.
You can take several approaches:
    1) increase physical memory or optimize the size of your cache.
    2) Talk to your vendor and find out a) when they will have a fix so that
you can use the run-time libraries. or b) if you have to compile in all the
.a libraries for the specific database functions you are performing.  You
may be able to get by with a subset of the libraries.
Another consideration is that the compiled in libraries are faster even
though they may use more memory.

Consider your options for the best choice in your situation.

DaveB

Quote:> Forgotten,

> Below are the new compile and link statements, are these optimal/correct
for
> AIX ?

Quote:>  -DSTRTOUL_SUPPORTED=IDI_TRUE -DUNIX -DSVR4 -DSVR4S -D_REENTRANT -DSTATVFS
_S
> UPPORTED -DAIO -O -c db_actions.c -DIDI_SERVER  -I/apps/v83/dm/include

Quote:>  -DSTRTOUL_SUPPORTED=IDI_TRUE -DUNIX -DSVR4 -DSVR4S -D_REENTRANT -DSTATVFS
_S
> UPPORTED -DAIO -s cgi_functions.o fldvalues.o ddb_arrays.o filltempl.o
> opi_err.o db_functions.o ddb_functions.o parse_query.o ./db_actions.o
> /apps/v83/dm/obj/opilib/opilib.a /apps/v83/dm/obj/opcslib/opcslib.a
> /apps/v83/dm/obj/opilib/opilib.a

 [shared vs. static libraries]

 Jose> If the program is only used one instance at a time, yes.  Else
 Jose> you get better performance with shared libraries.

as a general rule this is only true if you have multiple _different_
programs using the same shared libraries.

Multiple copies of the _same executable_ share all their code
regardless of the type of library.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

The convention of have a *.a and *.so just doubles the amount of disk
space required with no benefit.

So, are you sure the *.a file is an archive with static members?  Are you
sure that *.so is a shared object (and treated as such by the linker)?

Good question. I don't know. I used to compile without specifying the .a
libraries but only with -L/libdir and with option -lopilib. I assume
that -lopilib is used here to tell that the .so libraries in libdir should
be linked at runtime or not ?

Regards,

Louis