Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Office Holiday

Epic Games' offices will be on holiday from June 22nd to July 7th. During this period support will be limited. Our offices will reopen on Monday, July 8th. 

PVRTextureTool during Mac Build uses only one core

We have a moderate size iOS app that is very slow to build. Our build machine is a maxed out Late 2013 8-core Mac Pro w/ 64 gigs of RAM. We're currently on 4.6.1 release. Each device build take hours. Five or six hours on this beefy machine. When our team members working on laptops go to do device builds, it can take 12-15 hours or even more.

This is really unacceptable and is slowing us down.

Watching the build in top, the build uses a decent amount of all 8 physical cores during the earlier parts of the build (though doesn't appear to be taking advantage of hyperthreading), however, once it gets to doing PVR compression using PVRTexTool, it starts using only a single physical core, hovering between 90 and 95% utilization of a one core while the rest sit idle.

Is there any way we can workaround this? Are there any plans to fix it in future releases Ideally, it should be compressing on at least 8 threads to maximize the use of system resources.

Product Version: Not Selected
more ▼

asked Jan 22 '15 at 11:17 PM in Bug Reports

avatar image

291 15 26 44

avatar image Ravlek STAFF Jan 23 '15 at 07:52 PM

I believe this might be a known issue which we are hoping to fix in the near future. The problem is to ensure the editor doesn't eat up too many resources when in the background, we reduce usage of a number of things. Why does this matter? Well, the cooker is just the editor running stand-alone, so when the build process kicks off the cooker, it creates an editor running in the background and after about 15 seconds or so that process kicks in to low resource mode and stops utilizing more than one core. There is a very hacky work around for people who are at their machine. There will be a second editor instance running on the shelf. Clicking on that and making it have focus will kick the process back to the foreground which will enable it to use all the resources again. I'll bump this issue up in priority and see what we can do about getting it resolved sooner rather than later.


avatar image Kneebiter Jan 23 '15 at 09:01 PM

Thanks for the information. Would renice-ing the build process to a higher priority help at all? What about doing the build from Xcode or the command line instead of the UE editor?

avatar image Kneebiter Jan 30 '15 at 06:37 PM

So, for the record, I tried renicing the process to -20 (both the spawned process and the original one) after kicking off the build. It finished in 1.5 hours on an 8-core Mac Pro (Late 2013), which is much better than the 5 hours the previous builds have been taking.

avatar image [Epic] Gribbs ♦♦ STAFF Feb 13 '15 at 03:11 PM

Howdy Jeff,

Sorry about the late response. Just wanted to check in with you and see if your build time have been shorter as of late. Please be sure to let me know so that I may be able to close out this issue or further investigate.

Thanks and have a great day!

avatar image Kneebiter Feb 13 '15 at 03:41 PM


We haven't upgraded our engine since I posted this. We tried a few of the 7 previews, but never got far enough to do a build.

That being said, bringing the second instance of UE4 to the front, and renice-ing all of the UE4 processes to -20 does get us more acceptable build times.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

2 answers: sort voted first

Has there been any progress on this? We have finally managed to get automated builds using Jenkins, but anytime we rebuild lighting it takes several hours to create a build unless someone logs into the Mac and gives focus to the UE4Editor process (which drops the build time to 15 minutes).

I tried modifying the engine to get rid of the "low profile" mode but nothing I did worked. I tried making UEditorEngine::ShouldThrottleCPUUsage() return false when running a commandlet (which should be the case when cooking), but it had no effect, which leads me to suspect something else is at work here. The editor is sleeping something between 20 and 40 seconds between each texture that needs to be compressed. This only happens when compressing textures, which uses async tasks, but I couldn't find which could be causing the async tasks to wait so much time.

At least a pointer towards where I could look (and hack) in the code would be helpful.

more ▼

answered Jul 14 '15 at 07:07 PM

avatar image

358 8 11 26

avatar image wittlief ♦♦ STAFF Jul 15 '15 at 02:35 PM

Hi manoelneto,

On what version of the editor are you currently running?

Is your slowdown issue also occurring during the PVRTextool compression or just compression in general? If it's the latter, this may be a separate issue.

avatar image manoelneto Jul 15 '15 at 04:35 PM

I'm still on 4.5.1, but I was looking through the master branch source code trying to see if there is any changes about this and couldn't find anything (or I'm not looking at the right places).

The problem happens only when cooking new/modified textures. During other steps of the cooking/packaging process CPU usage is normal, but is abnormally low while compressing textures. It doesn't seem to be PVRTexTool: it only shows up in the activity monitor for a brief moment and then UE4Editor will idle for several seconds before firing it up again.

Bringing the UE4Editor process to foreground by clicking on its icon on the dock greatly speeds up the process and increases CPU usage. Switching away the focus to any other app drops the CPU usage and slows down the build time.

Here are the timestamps for compressing two lightmaps. It takes around 7 minutes to compress two textures In background and only four seconds in foreground. The suggestion for using nice/renice to increase process priority cannot be used in my case, since I'm using RunUAT.sh to build, unless I modify the UAT.

avatar image wittlief ♦♦ STAFF Jul 15 '15 at 04:45 PM

ok, I hate to do this since you've posted so much info here, but as your issue isn't involving PVRTexTool and its use of a single core specifically and this thread was, do you mind starting a new thread and shifting your information into it? That issue was fixed and yours is almost certainly something else.

Thanks very much!

avatar image manoelneto Jul 15 '15 at 09:26 PM

I'll do that. I have been a bit reluctant about posting questions since we couldn't afford time to upgrade from 4.5.1 yet (the project is pretty far along) and have been making do with backporting bug fixes from the newer versions when necessary.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Since the build times have been decreased, would you be ok with closing out this post since Peter has stated that this is a know issue? If closed and you see the issue continue to occur, you could reopen this issue so that I would be able to further investigate.

more ▼

answered Feb 13 '15 at 07:59 PM

avatar image

[Epic] Gribbs ♦♦ STAFF
11.8k 292 14 77

avatar image Kneebiter Feb 13 '15 at 07:59 PM

Sure, that's fine.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question