How can I make MS run faster?

[dbur]

I started a new very large design project and so I bought a new computer that is many times faster than my old one.

The problem is that MS editing features don't run any faster even though my computer is way faster.  The CPU's, memory, disc drives all show almost at idle, but MS just continues to plug along at the same old slow rate thinking about things, who knows what.

This is getting to be real old when working with large parts and schematics.

What's the deal, why doesn't a faster computer run MS any faster?

I suppose MS is just unable to use the performance available for some reason.  Is there any use at all in multi-core CPU's?

Win7 Ultimate, 64bit, AMD Athlon Phenom II, 1100T, 6 core, 8GB RAM.  MS 11.0.1

Thanks.

[clansing]

Hi dbur,

One suggestion that might buy you a little performance (if you aren't already doing it) is to turn off the schematic grid (under the workspace tab in the Sheet Properties). If large enough areas of a schematic are being redrawn and the dots are visible (zoom level at 100% or larger), then the time saved not drawing the dots might actually be noticeable in some situations.

I doubt it will be a large performance gain, but it might help a little. I'll let you know if any other ideas come to mind.

[GarretF]

Hi dbur,

A couple more suggestions.

1. Hide the spreadsheet view. Multisim is smart enough to not refresh the spreadsheet when it is not visible.

2. Hide the page border and ruler bars.

3. Run simulations using the COM API or the LabVIEW Multisim Connectivity Toolkit.

If you haven't already, do send your files to Tien or Nestor so that we take a look at the files. If things are slow, we want to investigate how we can make it faster.

[dbur]

Is there a way to keep the spreadsheet from opening every time there is a message?  (Like when you try to move something to somewhere it can't go)  I like it to stay closed sometimes since I'm trying to look at something else on my screen, like a data sheet.

I haven't noticed much difference when the spreadsheet is open or closed though I should try that next time I do something that effects a lot of connections.

I always hide the ruler.  I tried hiding the border and turning off the grid, but it didn't make a lot of difference.  I like the grid on anyway.

I'm not doing simulations.  I normally only do those with smaller files anyway.

This customer is very sensitive so I don't have permission to send files anywhere without NDA's yet.

Thanks,

David B

[GarretF]

Hi David,

There isn't a way to keep it from opening when there are messages, but as long as you are on the Results tab, that will have the same effect.

[_user32]

dbur,

What type of actions within Multisim are appearing slow to you (navigating/scrolling the schematic, copy/paste, component placement/manipulation, others...)?   You are saying that the CPU % is not close to 100% so I am wondering if there are certain actions that could be optimized - or perhaps all actions in general are not performing well.

Can you give us an idea on how the approximate number of HBs, pages or components and nets that are in your schematic.   Also are you using some of the larger pin count devices (such as multisection parts).   We can likely do a mock up with the same amount of components and detail on computer configuration similar to yours (OS, memory, etc..) and see if we can reproduce the slow response on the actions that you are seeing noticeably sluggish.

Regards,

Pat Noonan

National Instruments

[dbur]

In a schematic with 32 44pin IC's, eight 100 pin connectors & 2 90pin connectors it takes:

10 sec to rotate a 100pin connector

30 sec to connect the pins when I move it onto the wires with 'automatically connect when pins touch' selected.

In a circuit with one 140pin connector and two 100pin connectors (no HB's or subcircuits yet) it takes:

3 sec to rotate a 100pin connector

7 sec to connect the pins when I move it onto the wires with 'automatically connect when pins touch' selected.

This is kind of indicitve of all operations, they just seem slow and sluggish.  My CPU shows one core picking up a load and averaging about 60% during the delays, though sometimes higher.

I tried increasing the priority of the multisim task but it did not make any difference.  Resource monitor does not indicate that multisim is using any services during this time.  It also shows multisim as 'not responding' during the delays.  It does show the CPU speed is increased to near 100%, but the overall CPU is only at about 4%, with one core averaging around 60%.  Wait chain analysis says it's waiting on splwow64.exe.  (See the screen snip)

It kind of seems like the biggest issue may be MS only uses one core, but it still seems awfully slow for even just one core.

My system:

AMD Phenom II 1100T 6 core

8GB RAM

SATA 6 hard drive

Windows 7 64bit

[_user32]

dbur,

Yes that does appear to be slow to me as well.   I'll put together a mock up circuit to reproduce the problem and work with our AE team and R&D to see if they can provide some suggestions for improvement or let you know if this is some type of bug with some of the steps you've mentioned or some general speed optimization that needs to happen in Multisim.

Regards,

Pat

[_user32]

dbur,

I did get a chance to replicate the behavior you are seeing.   I tried an example circuit configuration a few different ways in an attempt to isolate the problem and I do have a suggested work around.  Note that I have a quad core PC running Win XP 32 bit.

#1 - large monolithic (single page) design with 32x 144pin IC symbols, 10x 100pin connector symbols and 2x 90 pin IC symbols.

I experience similar performance issues...  30 seconds to perform an automatic connection.  disconnecting took about 10-12 seconds

When I first started and there were 0 existing nets the, performance of automatic connections was around 14-18 seconds but grew to about 30 seconds when there were many net connections.

Similar to what you saw in the 8-10 seconds when rotating...

#2 - Just for kicks I added 2x 1000 pin connector (single section symbol) into the mix to the same schematic (had to use custom size schematic).

Autoconnection took about 4-5 minutes and disconnection about half that.

Rotating the 1000 pin connector (with no connections) only took about 8-10 seconds, although I did see some odd behavior when the symbol went off screen - so I'll need to look into that some more.

#3 - I broke up the schematic into a multi-page schematic and broke the schematic into 11 pages (8x 144 pin IC across 4 pages, 2x 100 pin connectors across 5 pages, 2x 1000 pin connectors on its own page, 2x 90 pin IC symbols on own page.

Performance was much better - connecting the 100 pin connector symbols only took about 2-3 seconds versus the 30 seconds previous...

#4 - I then created a new schematic and then broke up my 1000 pin part into a multisection component (2x 1000 pin symbol broken into 12 sections - with 150 being the largest section).

When I put them into a single page and autoconnected the pins in a 1-1 fashion between the 2 parts, I got similar performance when wiring from step #1 (18-30 seconds)...

When I put the symbols across multiple pages I got much better performance when connecting (2-3 seconds)... similar to the #3 above.

So - in summary I do believe there is some room for optimization in this specific feature and I will pass my findings to our R&D team for evaluation.   Please forward me any other tasks that seem to work more sluggish when you have these larger components in a design and I can evaluate.

My recommendation currently: For using the automatic pin to pin connection feature (creating automatic net connections by overlapping the symbol pins - which does save time), I do think a best practice is to use smaller sheet sizes and/or break up the design into separate pages (if/when possible) - and therefore Multisim needs to only manage a few nets being created at once.  The performance does seem to improve if you break up the larger symbols (100 pins or greater) into multisection parts (again when possible).

Note I did try other steps likely copy/paste, delete/undo and these steps seemed to perform ok across the different schematic configurations.   I am guessing at this time that there is something in the automatic pin to pin connection feature that doesn't scale well with large pin count devices.

Regards,

Pat Noonan

[dbur]

I did notice that if I undid the move and autoconnect, and then re-did it, it goes much faster than if I repeat the move and autoconnect manually.