roamer.exe performance via Automation API

[Anonymous]

I have noticed when using the Automation API that it spins up the roamer.exe process to handle it's work. The process never seems to use > 25% of the total CPU. Is there anyway to maximize the performance of the process? I have a system with a QuadCore Xenon and 8GBs of memory.

Also, I have noticed that even if I spin up more than 1 NavisworksApplication instance in different threads (resulting in more than 1 roamer.exe processes), and split the work between them, the total time to do my processessing doesn't decrease. Is it not capable in doing more than one operation at once? (the multiple roamer.exe's may be doing things concurrently, but whatever they are accessing may not be capable in doing things concurrently?)

thanks,

[Anonymous]

I too run the Roamer in the background for opening up my .nwf files and saving them as .nwd files.  I have batch files that start my .nwf models at different times during an hour. 

When running multiple batch files, you might notice that some of your models will be missing drawings in your .nwd the next time you open. 

The only thing I can see that's causing this is the process doesn't complete itself in the hour allocated and when it runs again through the scheduler program, something has to give. 

I have one .nwf file with about 800+ drawings in it that is rapidly increasing in size on a daily basis as the project moves on.  The only way I can update that .nwf/.nwd file is to shut down my other batches, run that one (over 2 hours processing time last I tried), and then start the other batches again. 

Task Scheduler doesn't have the marbles to make mods like this as far as I can tell. 

Definitely allocating more cpu power to the program would be a great help. 

I have a 4 core process and 16gb of ram and that model will still take over 2 hours to load up.  Finished size in the .nwd is over 280mb.   The .nwd will load in less than 40 seconds which is very nice but, when it comes to crunching the .nwf model, figure on taking a long lunch..

PJ

[xiaodong_liang]

Hi,

Firstly, Navisworks is not multi-threaded, so it will never use more than a single core on a multi-core machine. This explains why the you are only seeing 25% processor usage (one out of four cores).

Because it is not multi-threaded, starting up multiple copies will not make it go any faster. So in a word, no, Navisworks is not capable of doing more than one operation at once.

Of course you can start up multiple Roamers doing completely separate tasks, but they can’t communicate between them to work on the same task.

Hope this helps,

Regards,

Xiaodong Liang

Developer Consultant

Autodesk Developer Technical Services

[Anonymous]

Thank you very much for your reply.

So I assumed that navisworks isn't multithreaded and you confirmed it.

However, what I don't understand is why, then, launching multiple roamers.exe, each doing seperate tasks, doesn't result in an overall speed increase? (as I mention in my original post). Unless the bottleneck is some shared resource that each roamer.exe is trying to access (I/O perhaps?)

[dgorsman]

Plenty of bottlenecks to run into:

- 32 bit memory limitations on RAM useage

- running each roamer.exe process on the same source file(s)

- not ensuring each process is allocated to a different core

-  calling the processes in sequence, waiting for each to finish before spinning up the next

[Anonymous]

1) I am on a 64 bit machine with 8 GB, so not running into memory limitations and the machine is not spending lots of I/O accessing the swap when I have the multiple roamers.exe running concurrently (page file usage is very minimal)

2) I am definately not asking each roamer process to work with the same source files, although they may all be outputting to the same folder.

3) I let the OS handle which thread gets assigned to which core, all you should care about is efficiently managing the threads (i.e.: use thread pool, shared resources, etc.)

4) definately not the case

I've spent a lot of time on benchmarking the performance of my work load under single and multiple roamer processes, with proper worl load distribution among the threads, and I have seen very little gain in overall time. Watching the multiple roamer.exe process while the work is occuring suggests that there is something sequential going on, as one roamer.exe will take 0% CPU while another is using it. As I theroized in my original post: "the multiple roamer.exe's may be doing things concurrently, but whatever they are accessing may not be capable in doing things concurrently?"

Multi-core / threaded coding is second nature to me, hardly flying by the seat of my pants.

[dgorsman]

About point (3), have you tried forcing each roamer.exe process to a separate dedicated core?  If you are calling them directly then I don't think think the OS will automatically assign them to separate cores by default.

I do know at least one point of commonality - licensing.  I have seen users with multiple  occurences of the program running and only a single license is drawn from the pool.  Not sure how that comes into play during this kind of processing, possibly the 'heartbeat' check?