NONMEM Users Network Archive

Hosted by Cognigen

Re: NONMEM memory vs. run time

From: Nick Holford <n.holford>
Date: Mon, 08 Sep 2008 14:13:52 -0400


The executable building was explicitly excluded (please read my previous
email carefully). I cannot say how long it takes to create a swapfile
but I would be surprised if it took 5 seconds.

If you want to know if these results scale with model runtime and other
variables such as available RAM then I suggest you try it on your
datasets. I did this a long time ago and made it easy with WFN to build
and switch between different sizes of NONMEM according to the problem.
That way I dont need to waste time running test problems :-)


Elassaiss - Schaap, J. (Jeroen) wrote:
> Nick,
> Interesting observations. I however wouldn't be surprised if the
> additional 4-5 seconds would be due to I/O activities (swapfile,
> executable building etc.) rather than calculations. How do these
> differences scale with model runtime, i.e. for models than run hours
> rather than minutes, does the big/small nonmem difference increase from
> seconds to minutes?
> Best regards,
> Jeroen
> J. Elassaiss-Schaap
> Scientist PK/PD
> Clinical Pharmacology and Kinetics
> Schering-Plough
> PO Box 20, 5340 BH Oss, Netherlands
> Phone: + 31 412 66 9320
> Fax: + 31 412 66 2506
> e-mail: jeroen.elassaiss
> -----Original Message-----
> From: owner-nmusers
> On Behalf Of Nick Holford
> Sent: Monday, 08 September, 2008 17:12
> To: nmusers
> Subject: Re: [NMusers] NONMEM memory vs. run time
> Leonid, Darin,
> Here are some experimental results rather than theoretical predictions.
> I ran a problem (ADVAN6) with two 'sizes' of NONMEM created with NMQUAL
> using Wings for NONMEM. The 'std' size is the default NONMEM
> configuration. The '570' size is close to the 'big' version provided
> with NMQUAL. I ran the problems with an Intel core duo processor with 1
> Gb RAM compiled with Intel Fortran version 10.1024. I used NONMEM VI 2.0
> installed with NMQUAL-6.3.2 and Windows XP.
> I tried each size of problem two times. Run times exclude NM-TRAN and
> the compile/link step. You will see that the bigger NONMEM size took 5%
> longer to complete. There were no page faults visible with the Task
> Manager using either size.
> std =Mem Usage 51.1 M byte VM Size 97.1 Mbyte Runtimes: 80.88
> sec/ 81.82 sec
> 570=Mem Usage 199.8 M byte VM Size 1107.9 Mbyte Runtimes: 84.10
> sec/ 87.22 sec
> These results are similar to those I have observed before. The bigger
> versions of NONMEM run more slowly. This is why I prefer to match the
> NONMEM size to the problem size. For smaller problems (fewer parameter,
> fewer obs/subject) I use the std size. For bigger problems WFN allows a
> choice to increase either parameters, obs/subject or both.
> Nick
> Darin Perusich wrote:
>> The increase in memory consumption doesn't impact runtime positively
>> or negatively, unless of course your system doesn't have enough
>> physical memory to accommodate the increase. NONMEM's memory footprint
>> is directly related to the buffer values in the SIZES file, as you
>> increase the values the memory footprint increases to accommodate.
>> In the end processor speed is really the only thing that positively or
>> negatively effects NONMEM runtime.
>> Leonid Gibiansky wrote:
>>> Dear All,
>>> I noticed that the Nonmem installed with NMQUAL "big nm6" defaults
>>> instead of the standard ones results in approximately 10-times
> increase
>>> in the memory required to run Nonmem (on my recent problem, from 12
> MB
>>> to 140 MB). I am wondering whether anybody checked how this
> influences
>>> the run time. Is it better (in terms of the run time) to use standard
>>> sizes, or "big" is OK if you have enough RAM?
>>> Thanks!
>>> Leonid

Nick Holford, Dept Pharmacology & Clinical Pharmacology
University of Auckland, 85 Park Rd, Private Bag 92019, Auckland, New Zealand

Received on Mon Sep 08 2008 - 14:13:52 EDT

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to:

Once subscribed, you may contribute to the discussion by emailing: