1

I'm facing with issue related to long loading time of the empty map from Here-SDK-iOS.

I opened sample project and looks like it freeze for some time, the code for initialisation is next:

  override func loadView() {
    super.loadView()
    
    NSLog("%@", ">>>>>>>>>> Load View \(Date())")
  }
  
  override func viewDidLoad() {
    super.viewDidLoad()
    
    mapView = MapView(frame: view.bounds)
    view.addSubview(mapView)
    
    mapView.mapScene.loadScene(mapScheme: .normalDay, completion: self.onLoadScene)
    mapView.gestures.tapDelegate = self
    
    NSLog("%@", ">>>>>>>>>> View Did Load \(Date())")
  }

  override func didReceiveMemoryWarning() {
    super.didReceiveMemoryWarning()

    mapView.handleLowMemory()
  }

  func onLoadScene(_ error: MapError?) {
    guard error == nil else {
      print("Error: Map scene not loaded, \(String(describing: error))")
      return
    }

    // Configure the map.
    let camera = mapView.camera
    camera.lookAt(point: GeoCoordinates(latitude: 52.518043, longitude: 13.405991),
                  distanceInMeters: 1000 * 10)
  }

The log:

2021-06-25 08:45:27.500549+0300 testDrawing[50019:31547554] >>>>>>>>>> Load View 2021-06-25 05:45:27 +0000

...

2021-06-25 08:45:31.301998+0300 testDrawing[50019:31547554] >>>>>>>>>> View Did Load 2021-06-25 05:45:31 +0000

As u can see there is about 4 sec to init the map with initial location. Note: I use freemium account for testing.

I also can see additional warnings like

[WARN ] harp-sdk - Ignore adding invalid observer

[WARN] ResponseFromJsonBuilder - Absent value, response=olp::authentication::IntrospectAppResult, field=description

[INFO ] harp-sdk - Adding data source

[INFO ] Storage.LevelDB - Cleared other DB in folder: "/Users//Library/Developer/CoreSimulator/Devices/61082972-C4BE-42E2-9696-0D2458D475D5/data/Containers/Data/Application/74E993BF-7111-4E08-A27F-A7F62B3ADA1D/Library/Caches/v1/sSR8TFucGSrS94S4sDvrsA/analyticsData/events.sqlite

[INFO] ThreadPoolTaskScheduler - Starting thread 'OLPSDKPOOL_0'

The most time consuming operation - is Cleared other DB in folder- about 3 sec.

Can anyone advice what's the reason for this behaviour.

---- UPDATE -----

I also receiving random crash

enter image description here

version = heresdk-explore-ios-4.7.5.0.5737

---- UPDATE -----

Few mode tech details:

For issue «freeze on start":

tested on Mac with M1 and simulator (12 Pro, iOS 14.5) and on device 12 Pro iOS 14.5. On device lag a bit smaller - 1-3 sec, on simulator - up to 7 sec. heresdk-explore-ios-4.7.5.0.5737 heresdk-navigate-ios-4.7.6.0.5863

For "crash on start":

12 Pro, iOS 14.5 both heresdk-explore-ios-4.7.5.0.5737

---- UPDATE ----

Hi, the crash with analytics service must be fixed in upcoming release. The most time consuming operation - is Cleared other DB in folder- about 3 sec. There is no evidence that this operation consumes 3 sec, probably something happen after this operation. – Hsilgos

@Hsilgos,

Yes, there is no evidence that exactly this operation consume 3 sec - it's just a guess from my side (when I remove sdk - everything works instantly, so this is simple check).

Here few screenshots from profiler:

enter image description here enter image description here

Here is the trace file

Here u can see that HARP.SDK.RENDERER (map renderer I guess) eat a lot of resource, and looks like MainThread is waiting until it's done.

enter image description here

Again - this is just a guess.

Another point for improvement - add support for running fat on arm64 Darwin simulator on M1. For not I need to use Rosetta ( - this disappointing....

---- UPDATE ----

Issue with drawing performance - example (when around 200 items are drawn at once, to be more precise - one-by-one - there is no API for batch drawing):

enter image description here

Look at second drawing area - the performance issue is more visible there

hbk
  • 10,908
  • 11
  • 91
  • 124
  • 1
    I have added the same logs as you did and tested with https://github.com/heremaps/here-sdk-examples/tree/master/examples/latest/explore/ios/HelloMap I get around 1-2 seconds. I never experienced the crash you have seen, nor the Storage.LevelDB log. I have tested with HERE SDK for iOS (Explore Edition) 4.7.7. - which is a much newer version, so maybe things have improved meanwhile. It would probably be advisable to test with a newer release and also, it would be good if you can share which device you have used for testing. On simulator it usually starts slower. – Nusatad Jul 13 '21 at 15:19
  • upvote the question to get the more attention please – hbk Jul 13 '21 at 15:21
  • PS: When you are using a M1-based computer to run Xcode, a workaround is needed to run the simulator (as mentioned in the documentation), so I assume this means that the x86 architecture needs to be emulated by Rosetta and this can further slow down. On non-M1 chips the simulator runs with x86 and it is therefore faster (by default, the HERE SDK ships with arm and x86 binaries, but on M1 this works differently). – Nusatad Jul 14 '21 at 08:45
  • @Datasun U absolutely right, I understood that if I run Xcode in compatibility mode with Rosetta this can bring the slowdown. But I didn't use Rosetta, instead I exclude arm64 for simulator architecture: Build Settings-> Excluded Architecture-> Any iOS Simulator SDK-> value arm64` or in other words `EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64`. The problem here is not in simulator slowdown, but more in device slowdown... which is not acceptable I guess – hbk Jul 14 '21 at 09:39
  • Hi, the crash with analytics service must be fixed in upcoming release. `The most time consuming operation - is Cleared other DB in folder- about 3 sec. ` There is no evidence that this operation consumes 3 sec, probably something happen after this operation. – Hsilgos Jul 16 '21 at 12:22
  • @Hsilgos thanks for the fix, also, please check update In equation (to big for comments). – hbk Jul 16 '21 at 12:49

1 Answers1

2

The HERE SDK team announced today that it is planned to add explicit support for M1 arm64 simulator builds. It is not clear yet when and how this will happen, but since it is missing right now, running a simulator on an Apple M1 processor will slow things down a bit in comparison to real devices. However, for me, running simulator on M1 is still faster than running a simulator on a non-M1, just because the M1 is incredibly fast and my non-M1 MacBook has not the fastest setup.

Also, the analytics crash seems to be a known issue. So, hopefully, we can see a fix for both soon.

Nusatad
  • 3,231
  • 3
  • 11
  • 17
  • @Datasub - thanks for update. How about investigation for long loading time (thus this easily reproducible on real device). Also, I have additional question regarding drawing performance - should I open a new thread or I can update the question here – hbk Jul 19 '21 at 08:03
  • added small update to question - to be more concrete – hbk Jul 19 '21 at 08:13
  • There's no support for batch drawing, so a large number of assets may have an impact. Sounds like a feature request, so I would expect it is best if you contact the HERE team directly and ask for it. – Nusatad Jul 19 '21 at 11:35
  • Ok, thanks for response, already asked - the answer is - such activities is not planned, u can use existing API :( – hbk Jul 19 '21 at 11:36
  • In total after almost a month of discussion - 1 out of 4 problems (crash, m1, slow on device, multi-drawing) solved ). One more point for improvement - add package manager for libs… for now 600mb of happiness (size of fat xcframework) is not the best solution… – hbk Jul 19 '21 at 11:40
  • @hbk, M1 should be supported now. Size of xcframework shouldn't be a problem, because your final release app is much smaller. The purpose of xcframework (it's not "fat" framework btw) is to provide set of frameworks for all possible cases: device, simulator, watches, etc. You may think about it as about archive with frameworks. Also subset for device is big because it contains bytecode so it allows appstore to adapt your app for specific device architecture when you publish your app. After Appstore processing final app is much smaller. – Hsilgos Nov 23 '21 at 10:02
  • @Hsilgos thanks for update - it’s good to know that something is moving in right direction; regarding the size - my concern was about integration, u support only “drag-and-drop” way, this is obviously not the best case, thats why i asked about sp support or at least cocoa-pods or some other package way … Think not only about dev(as u mention bitcode, various of device, etc) but think also about ops - what u should do with 600mb when u want quickly to run a build or in other cases; . By the way I ended up with sliced version of the xcframework, with custom mod for plist info and sp on the repo. – hbk Nov 23 '21 at 10:15