21

So I've now converted my project to use Swift 4 in Xcode 9, and have started testing my app. It's a big app with four distinct tabs, and nearly everything is working as expected. One of the tabs is a map, using GoogleMaps. I have never had any trouble with it, but when built with Xcode 9 and shown in Simulator, it uses over 100% of CPU when moving the map, and it lags very much. Here is the debug navigator when running on a simulator. We do some custom drawing, but not 102% worth of drawing.

CPU usage

This only started happening after I updated to Xcode 9 and Swift 4. When debugging in Xcode 9 on an iPhone 7, 8 or X simulator, all with iOS 11, it goes just over 100% CPU, and it completely stops the UI from updating for about one second each time I try to move it. I start the drag-gesture, but the UI only updates once a second. Effectively giving me about 1fps.

However, when debugging in Xcode 9 on an iPhone 6 simulator with iOS 9, it gets up to ~90% when moving the map and not lagging nearly as much. I'm guessing I get about 20-30 fps here. (This might be the same fps I get in simulators on Xcode 8. Map has never been really smooth on simulator..)

When running on an actual device (iPhone 7, iOS 11), the CPU uses about 40% when constantly moving the map, and is working very smooth with no lags at all (60fps).

I also get this in the output as soon as I open the tab with the map, but I think it's irrelevant to this particular question:

Main Thread Checker: UI API called on a background thread: -[UIApplication applicationState]
PID: *****, TID: *******, Thread name: com.google.Maps.LabelingBehavior, Queue name: com.apple.root.default-qos.overcommit, QoS: 21

This says that GoogleMapsAPI calls [UIApplication applicationState] on a background thread..

I am using the latest version of GoogleMaps: 2.4.0. As far as I know, this version may not support Xcode 9/Swift 4 etc, but I can't find anything about a new version.

Sti
  • 8,275
  • 9
  • 62
  • 124
  • i think you should ask this on google Development forms too. Because they could give us a batter answer to us. – Abu Ul Hassan Sep 21 '17 at 12:46
  • @AbuUlHassan I thought about it, but they state on their support page for GoogleMapsAPI that StackOverflow and these custom tags (google-maps) are monitored by several members of the GoogleMapsAPI-team, and encourage us to use it ( https://developers.google.com/maps/documentation/ios-sdk/support ) I really don't like their issue tracker anyway.. – Sti Sep 21 '17 at 13:12
  • @Sti Are you tested it in real device? – Aznix Sep 21 '17 at 22:31
  • 2
    @Aznix As I stated in the question, when running on a real device it runs smooth. – Sti Sep 21 '17 at 22:32
  • well this is rediclous – Abu Ul Hassan Sep 22 '17 at 05:31
  • @Sti I have the exact same problem. Hopefully google updates their sdk soon – Siyavash Sep 22 '17 at 12:09
  • See my answer; Google Maps uses OpenGL to render so the bug I mentioned negatively impacts both it and MapKit. – russbishop Sep 24 '17 at 01:35
  • @russbishop it will down performance of real time device? – Hitesh Oct 05 '17 at 11:05

1 Answers1

18

Update: This issue is fixed in Xcode 9.1 beta 2

There is a bug in OpenGLES.framework that causes it to skip loading the LLVM JIT and fall back to interpreting shaders. This has a severe performance impact on the Simulator since it is entirely software-rendered OpenGL (this includes CoreAnimation, SceneKit, etc).

edit: To clarify, the symptoms of this are exactly what you describe: 100% or greater CPU usage and <1fps rendering. This affects the Google Maps SDK and MapKit.

As a temporary workaround you can copy libCoreVMClient.dylib from Beta 3 into the Xcode 9 GM and performance should be restored to what it was previously. This must be done for each platform runtime separately.

For iOS this is located at: Xcode[-beta].app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/OpenGLES.framework/libCoreVMClient.dylib

For tvOS this is located at: Xcode[-beta].app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/OpenGLES.framework/libCoreVMClient.dylib

For watchOS this is located at: Xcode[-beta].app/Contents/Developer/Platforms/WatchOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/watchOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/OpenGLES.framework/libCoreVMClient.dylib

russbishop
  • 16,587
  • 7
  • 61
  • 74
  • I’m still a bit confused.. does this bug have any impact on real devices, or only simulator? I get that it doesn’t use 100% cpu on real device, but does it impact at all? And if I use the dylib from b3 - then compile and build and export my app to AppStore, would this build be any different than a build using the GM-dylib? I’m not entirely sure what kind of file this is, and I’m reluctant to switch it out in case it has unforeseen side effects. – Sti Sep 24 '17 at 09:34
  • 1
    This bug does not affect on-device performance. Replacing the dylib does not affect what gets built or submitted to the app store. It is purely within the Simulator runtime. You can also download and use the iOS 10.3 runtime (which does not have this bug) with Xcode 9. – russbishop Sep 25 '17 at 08:13
  • Good answer but where can we download the old file? An upload would be much much appreciated. – adsy Sep 26 '17 at 22:54
  • I'm sorry, I can't help with that. We stop officially distributing the betas when the GM is released. Perhaps a friend still as a copy of the Xcode 9 beta 3? – russbishop Sep 27 '17 at 00:38
  • 2
    Working libCoreVMClient.dylib can be downloaded from here (Xcode 9 Beta 3) https://www.dropbox.com/s/1bdyh86eo01x2em/libCoreVMClient.dylib?dl=0 – Kostya Kurilov Oct 04 '17 at 14:35
  • According to this discussion, 9.1 still suffers this problem https://forums.developer.apple.com/thread/83570?start=105&tstart=0 – Alex Sorokoletov Nov 17 '17 at 00:58
  • @AlexSorokoletov Perhaps that is a different issue. The OpenGL issue was definitely fixed. The Simulator still uses a software renderer (no GPU acceleration) so performance is fairly poor. – russbishop Nov 20 '17 at 18:46
  • I would add for anyone else: if you would like to see GPU-accelerated rendering in the Simulator please file radars or send in feedback to that effect. – russbishop Nov 20 '17 at 18:56