Polygons - automatic repour on error

This annoying window has been driving me crazy for years already. Please, add an option to disable it in future releases.

Polygon re-pours are so slow on all but the most trivial of boards, trying to work with auto re-pours would drive me insane(r).

Pouring polys is the very last thing I do on a board.

Polygon re-pours are so slow on all but the most trivial of boards, trying to work with auto re-pours would drive me insane(r).

Pouring polys is the very last thing I do on a board.

Hi @voltsandjolts,

If CS performance is bothering you, then you could run the DXP.exe (CS executable) with high priority. From I what I saw, CS is run mainly on a single thread/processor and running the executable as high priority will help.

From another forum I learned that you could automate this by using a small open-source utility named 'Bat to Exe Converter' which can be downloaded from here: Bat To Exe Converter | F2KO Software

From the same forum (it's another user work, I only copy/paste here) the BAT file should look like this:

@echo off
IF [%1] == [] (
Start "Altium Circuit Studio" /high "C:\Program Files (x86)\Altium\CS\DXP.orig.EXE"
REM echo "There is no input file"
) ELSE (
Start "Altium Circuit Studio" /high "C:\Program Files (x86)\Altium\CS\DXP.orig.EXE" %1
REM echo "Input file is %1"
)
REM pause

assuming that your CS installation folder is the default one.

Using this BAT as a source you will create a new DXP.exe file which is more or less an "shortcut" to the real DXP.exe file which now needs to be renamed to DXP.orig.exe

You also need to rename the following files from:

dxp.exe.config

DXP.exe.manifest

to:

dxp.orig.exe.config

DXP.orig.exe.manifest

You can still run the CS as you used to but this time you do it from the renamed file: DXP.orig.exe

If you want to run CS as a high priority process you do it from the new "shortcut" DXP.exe

If you trust running an executable from an outside source I post here a link with the small executable that I just created through the same process just described (and also tested it). I also found and used  in this executable the CS icon.

If you use the file in the following link, unzip it and remember also to rename the original files as mentioned above.

https://cp.sync.com/dl/79aeb2b00/chvma4pg-3bqfmduj-tqdf98p9-h8v38qri

Interesting idea - have you seen any difference in performance by using a higher process priority. I would have thought that it would not make much difference unless you are seriously multitasking on your computer. It would be great to get a comparison if it boost performance.

Thanks for the info on process priority, however, for pouring polys it made no difference for me.

I'm running a HP Z-book i7-7820HQ 16GB.

The board I'm working on (approx 100x150mm) takes 8 seconds to pour two large polys, 4 secs to repour.

Making the dxp process high priority didn't speed this up unfortunately.

Who knows, maybe the CS code is pour_poly() then sleep(4000). That would not surprise me.

Hi Peter,

Perhaps the improvement is not that big and it depends on the setup. The current system is a notebook set with balanced powerplan and I had only a tiny bit of improvement (Acer Helios 300, i7-8850H, 16GB).

I can open CS with a medium-sized project loaded, in about 9". Using the original shortcut, it loads in about 10".

CS is installed on the C drive (Intel 600p NVMe SSD) the project is on a 5400RPM WD HDD.

Dedicated antivirus running in background.

But on a previous system (i7 first generation, 12GB RAM, normal SSD) the performance improvement was greater.

Yeah, just realized that on my newer notebook, the performance difference is not that big. For the pours I use a set of key shortcuts (P = Rebuild All and O = Set All to Unpoured)  and switch between those 2 states as needed. In a smallish projects (112 components and about 90 nets, 3 poly's) the change between poured and unpoured state is almost instant. But the polygons are not overlapped, they are 2 on top and one on bottom layer.

One useful tip of polygons do start to get slow (usually bring up the property dialog) is to split into two or three. I'm not certain but once the number of vertices increases (mainly due to components and tracks that are poured over rather than just size/area) the times increase exponentially (well non-linear) and splitting the polygon in two doesn't just half the time but can reduce back to pretty much zero. My understanding is that CS is mostly single threaded so perhaps difficult to boost performance by messing with process priorities. However I do remember going back many years to early hyperthreaded Pentiums that some FPGA software would run much faster once you turned off hyperthreading so always worth investigating ways of improving performance.