Re: Multigen load is real slow...

New Message Reply Date view Thread view Subject view Author view

Russell Suter (russell++at++ctasim.com)
Mon, 18 Nov 1996 14:03:14 -0700


On Nov 15, 3:01pm, Marcus Barnes wrote:
> Subject: Re: Multigen load is real slow...
> On Nov 15, 1:36pm, Russell Suter wrote:
> > Subject: Multigen load is real slow...
> > Hey again,
> >
> > I have a Multigen database that took a little less than a minute to load
> > with pf1.2 and Irix 5.3. Since going to the IR with pf2.1 and Irix 6.2,
> > the load takes about 2.5 hours. Yes, that's hours. What happened?
>
> I can imagine some circumstances where you might use more RAM in the new
loader
> than in the older one. This has to do with large color palettes and external
> reference palette overrides. Raise your notify level to PFNFY_DEBUG and
verify
> that you are not reloading the same external references more than once,
unless
> you intended it. To help you fully, I will ask you these questions for
> starters:
>
> What version of the OpenFlight loader are you using with 2.1?

14.2b

> What Flight or OpenFlight version is the database(s)?

The database was created long before I came on board but I believe 14.0.
That's the version of Multigen we have.

> Are you using external references? What version is the referencing file?

If I understand you correctly, Yes. We have a Multigen flight file which
references other Multigen flight files and loads them during the load.

> Are you using MIPS II binaries?

using -mips2 -o32

> How much RAM does you machine have?

256MB

> How much swap space does your machine have?

 # path pri pswap free maxswap vswap
 1 /dev/swap 0 514.00m 489.61m 514.00m 0.00k

> What are your shell "limit" values?

cputime unlimited
filesize unlimited
datasize unlimited
stacksize 65536 kbytes
coredumpsize unlimited
memoryuse 248624 kbytes
descriptors 200
vmemoryuse unlimited

>
> > I'm guessing that its not using physical memory but starting to do virtual
> > paging a little too early. The problem occures in my application as well
> > as perfly. The first part of the load is real fast but it reaches a point
> > and just crawls.
>
> Use osview or gr_osview to verify your suspicion. If you are hitting swap
> space then the short answer is to buy more RAM.
>

It does not appear to be a swap space problem. With osview, it now appears
to be compute bound. I've got 4 processors running between 75% and 100% and
the only thing running is perfly. RAM is comsumed at about 1MB/5seconds.
It is really wierd. The database references about 24 flight files. The
first 7 load within 5 seconds. The rest take about 10 to 15 minutes each.
I can load each file individually with perfly in about 3 to 4 seconds. Why
would it start so quickly and then just die?

> Regards.

Thanks much!

> --
> + Marcus Barnes, Technical Staff mailto:marcus++at++multigen.com +
> + Multigen Inc. http://www.multigen.com +
> + 550 S. Winchester Blvd. phoneto:1-408-556-2654 +
> + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 +
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Marcus Barnes

-- 
Russ
________________________________________________ ______________________________
Though my eyes could see                        | Russell Suter
         I still was a blind man.               |    Voice : (303) 889-1262
                Though my mind could think      |      Fax : (303) 889-1210
                        I still was a mad man.  | Internet : russell++at++ctasim.com
________________________________________________|______________________________
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:58 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.