Performance issues on a 4K screen

Gathar

Hello,

I would like to report some performance issues I had when working on my battlemap for Shessar contest. I have a 4K screen, and when I worked in full screen, as soon as I turned the effects on (even at the beginning of the map, with very few objects, when I had only the default sheets and effects, and had even removed some of them), the redraw time was very long (about one minute and a half each time). And it crashed quite often. Without effects, it was almost instant.

What surprised me, though, was that I reduced the size of my window so that it was about 1/4 of the screen. Having the total number of pixels to update divided by 4, I expected to have the drawing time divided by 4 too, more or less, which would be about 25s. However, at that size, the redraw time was almost instant, clearly less than 1s. I had seen many people before telling that with CC3+, they could work with effect on, and never could understand how it was possible before I reduced my window size.

So, this means that at least one of the effects is highly non-linear in the amount of pixels it has to draw. Do you have any idea which effects may exhibit these non-linear behaviour, so that I can avoid them in my future drawings (or add them right at the end of the drawing process, if I really need them)?

Thank you,

Loopysue

How interesting!

Maybe you could work out which ones were problematical by switching the effects off one at a time, sheet by sheet, until processing time suddenly pops to instantaneous?

jslayton

There are a number of effects whose execution time goes up according to the cube of the image size rather than the square (that is, doubling the image dimensions will get an 8x increase in time rather than a 4x increase). The point light filters are particularly bad this way.

As Loopysue suggests, it may be a matter of checking the redraw times at two sizes. One way to get a detailed comparison is to:

0) ensure that you have a c:\temp directory.
1) load your drawing in CC3+
2) turn on effects
3) maximize your CC3+ window
4) type in REDRAWTIME to generate a timing report in c:\temp
5) close the "Redraw time" window
6) resize your CC3+ window to be about half the screen size in each direction (about 1/4 the total pixels).
7) type in REDRAWTIME to generate a timing report in c:\temp
8) close the "Redraw time" window
9) post the two cc3redrawtiming_*_*.txt files from c:\temp for comparison.

If you open the individual cc3redrawtiming files you will see a detailed breakdown of everything that the effects system is doing and how long the stages take.

JimP

built-in trobleshooting ! I like it !

Gathar

Here are some measurements I made. And they are quite strange.

The first in time was 1/4 screen.
The second was full screen. But the result got displayed on the screen long before I could get back to work, as if the program was still busy long after the dump was finished. And it tells me about a rendering time of about 17s, which is much less than the total time I have to wait.
The third one I did to see if I could reproduce this. And not only I could, but the result file is also twice as big as the previous one, just as if it was rendered twice (and for instance, I see something mentioned "Wall Shadow, Point Light Finalize" 12 time, while it appears only 6 times in the other files). The long times seem to be centred around this effect, but basically, it goes from 1s to 6s, which does not explain the whole perceived difference.
The last one was a 1/4 screen too.

I hope you can make more sense out of it than I could

Thank you!

jslayton

The biggest time element looks to be RenderRotatedImage, which is the part of the system that renders rotated fills and symbols. This is a city map, right?

Except for the unexpectedly large RenderRotatedImage times (which are likely due to loading higher-resolution symbol images due to the higher-resolution screen), most of the filter times look reasonable to me. It's possible that the system is in fact rendering the image multiple times. It's also possible that there is unexpected memory management overhead, perhaps due to running out of system memory (possible with 64-bit systems having 4GB or less of system memory) or video card driver performance.

About the only thing I can ask at this point is if the CPU is running at 100% during the whole time or if it falls off after the initial rendering. The quickest way to check this is via the performance tab of the task manager (Ctrl_Shift+Escape to bring up task manager).

Gathar

This is the memory/processor profile while rendering full screen. This time, the rendering lasted for about 30s. During the whole rendering, the processor was high. As for memory, I have 20Gb, with more than 10 available.
This is not a city map, but a battlemap (it was done for Shessar contest, you can download it here). I used the count all command, which told me the following statistics:
705 2D Point Entities 2240 2D Line Entities 837 2D Circle Entities 404 2D Arc Entities 55 2D Ellipse Entities 196 2D Elliptical Arc Entities 554 2D Path Entities 240 2D Polygon Entities 1069 2D Smooth Polygon Entities 190 2D Text Entities 215 Symbol Definition Entities 213 Symbol Reference Entities 5 2D Text Attribute Entities 1 2D Multipoly Entities 3072 XP Entities 10 Control Points Entities 1 File Notes Entities 10009 Entities occupying 1273.51k of memory

Gathar

I just noticed two more informations:
- With each redraw, I get more used memory (see screenshot, I made 3 redraws after the first one)
- If you look at the redraw at the middle, it was twice as fast as the other redraws. With a classical redraw, the screen if first frozen with the previous picture, then switches to a full dark green screen, then back to the new picture. When I had this faster redraw, it switched directly from the old picture to the new one, no green screen in the middle.