This is my scenario Model: MacBook Pro 15" Model ID: MacBookPro2,2 Processor type: Intel Core 2 Duo Processor speed: 2.16 GHz Processors: 1 Cores: 2 L2 Cache (per processor): 4 MB RAM: 2 GB Bus speed: 667 MHz Boot ROM version: MBP22.00A5.B07 SMC version: 1.12f5 MacBookPro:~ fabrizio$ echo $ARGYLL_REV_CACHE_MULT 1.1 MacBookPro:~ fabrizio$ ps -ue USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND fabrizio 301 97.9 -0.1 29792 2788 p1 R+ 9:30AM 2:28.03 colprof -v -kr -l240 -L100 -cpp -dpp IFRA26 TERM_PROGRAM=Apple_Terminal TERM=xterm-color SHELL=/bin/bash TERM_PROGRA fabrizio 300 0.0 -0.0 27728 816 p1 S 9:29AM 0:00.01 -bash PATH=/usr/bin:/bin:/usr/sbin:/sbin SECURITYSESSIONID=b23230 HOME=/Users/fabrizio SHELL=/bin/bash USER=fabrizio fabrizio 305 0.0 -0.0 27728 820 p2 S 9:30AM 0:00.01 -bash PATH=/usr/bin:/bin:/usr/sbin:/sbin SECURITYSESSIONID=b23230 HOME=/Users/fabrizio SHELL=/bin/bash USER=fabrizio One of the CPU is working at 100% all the time but the amount of RAM used seems to be far from the limit set by ARGYLL_REV_CACHE_MULT. Fabrizio Il 14/08/08 02:25, "Graeme Gill" <graeme@xxxxxxxxxxxxx> ha scritto: > > No, I don't think I've seen this. The speed depends heavily on the > processor speed, and to a degree on the amount of memory though. > In creating the B2A table, about half the available RAM will > be used, but other applications running can interfere with this > (I notice for instance that if I've been running SeaMonkey for a while, > and then run colprof, that MSWindows doesn't kick SeaMonkey out of > memory, and colprof thrashes, slowing to a crawl.) > > You can check if colprof is running efficiently by pulling up > a performance monitor (ie. ActivityMonitor on OS X, or top > for Linux or OS X on the command line, or TaskManager on > MSWindows), and look at the CPU usage history. If one > processor is being used 100% (ie. 2 processor system, total > 50%) then it is running flat out. If it's less than this, > then it's not getting access to its RAM, and is probably > swapping to disk. If this is the case, look at how much > RAM you have, and which processes are using it. > > Graeme Gill. > >