Skip to content
This repository has been archived by the owner on Jan 12, 2019. It is now read-only.

CardIO view is slow to load #64

Closed
andyzei opened this issue Aug 18, 2014 · 4 comments
Closed

CardIO view is slow to load #64

andyzei opened this issue Aug 18, 2014 · 4 comments

Comments

@andyzei
Copy link

andyzei commented Aug 18, 2014

Seeing lots of time being spent in viewDidLoad, most of which is spent in -[CardIOBundle saveBundle:].

Below is a trace -- is there any way to mitigate this?

Thanks,

Andy

Running Time    Self        Symbol Name
460.0ms  100.0% 0.0     -[CardIOViewController viewDidLoad]
446.0ms   96.9% 0.0      CardIOLocalizedString
446.0ms   96.9% 0.0       CardIOLocalizedStringWithAlert
4.0ms    0.8%   0.0        -[CardIOBundle NSBundle]
2.0ms    0.4%   0.0        +[NSLocale preferredLanguages]
13.0ms    2.8%  0.0        +[CardIOLocalizer localizerForLanguageOrLocale:forBundle:]
427.0ms   92.8% 0.0        +[CardIOBundle sharedInstance]
427.0ms   92.8% 0.0         dispatch_once_f$VARIANT$up
427.0ms   92.8% 0.0          _dispatch_client_callout
427.0ms   92.8% 0.0           __30+[CardIOBundle sharedInstance]_block_invoke
427.0ms   92.8% 0.0            -[CardIOBundle initPrivate]
427.0ms   92.8% 0.0             -[CardIOBundle expandBundleAndSave]
1.0ms    0.2%   0.0              objc_object::sidetable_release(bool)
421.0ms   91.5% 0.0              -[CardIOBundle saveBundle:]
1.0ms    0.2%   0.0               objc_object::sidetable_retain()
1.0ms    0.2%   1.0               objc_msgSend
6.0ms    1.3%   0.0               -[NSFileManager createDirectoryAtPath:withIntermediateDirectories:attributes:error:]
411.0ms   89.3% 0.0               -[NSData(NSData) writeToFile:atomically:]
411.0ms   89.3% 0.0                _NSWriteDataToFileWithExtendedAttributes
99.0ms   21.5%  0.0                 rename
25.0ms    5.4%  25.0                    lstat
3.0ms    0.6%   3.0                 close
169.0ms   36.7% 0.0                 _NSCreateTemporaryFile
38.0ms    8.2%  0.0                 _NSCleanupTemporaryDirectory
1.0ms    0.2%   1.0                 0x778f08
1.0ms    0.2%   0.0                 0x7771fd
4.0ms    0.8%   0.0                 0x7771f1
30.0ms    6.5%  0.0                 0x777107
1.0ms    0.2%   0.0                 0x7759bf
7.0ms    1.5%   0.0                 0x77597f
1.0ms    0.2%   1.0                 0x7758c0
2.0ms    0.4%   0.0                 -[NSString(NSPathUtilities) getFileSystemRepresentation:maxLength:]
2.0ms    0.4%   0.0                 -[NSFileManager fileSystemRepresentationWithPath:]
28.0ms    6.0%  0.0                 -[NSData(NSData) enumerateByteRangesUsingBlock:]
1.0ms    0.2%   0.0               -[CardIOBundle bundlePath]
1.0ms    0.2%   0.0               +[NSPathStore2 pathStoreWithCharacters:length:]
5.0ms    1.0%   0.0              -[CardIOBundle expandBundle]
1.0ms    0.2%   0.0      -[UIViewController(EmptyBackButton) mob_viewDidLoad]
12.0ms    2.6%  1.0      -[CardIOViewController makeButtonWithTitle:withSelector:]
1.0ms    0.2%   0.0      -[CardIOView initWithFrame:]
@josharian
Copy link
Member

-saveBundle: is generated by https://github.com/paypal/baler. If you wanted to poke around yourself, that'd be the place to look. I'll leave further consider to @dgoldman-ebay.

@dgoldman-pdx
Copy link
Member

@andyzei interesting.

As @josharian indicated, the time is being spent within our baler code, which is how we get around the impossibility (to date) of including a standard NSBundle of images and strings inside our SDK. Specifically, from your trace it looks like the bulk of time is being spent within the system calls that create, write, and rename the temporary files representing the bundle.

I believe that iOS 8 will allow us to switch over to using actual NSBundles within the card.io SDK. But as we always support one version of iOS backward, we won't be able to completely drop baler until iOS 9 releases. And I'm a bit hesitant about including both iOS 7 and iOS 8 paths, since that would double the size of the resource portion of our SDK.

Hmm. This time-consuming code gets called only for the first call into the SDK that results in the need to fetch an image or string. One workaround might be for us to provide an optional SDK "initialization" API -- your app could call this new API well before asking card.io to present a view, and card.io could do these file manipulations on a background thread. Hmm...

@andyzei
Copy link
Author

andyzei commented Aug 22, 2014

Cool -- thanks a ton for the info -- that's super helpful. Will stew on this.

@dgoldman-pdx
Copy link
Member

@andyzei we've now added a preload method to speed up the appearance of the CardIOViewController.

Thanks again for bringing this to our attention!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants