WWDC2017 Session 244

Transcript

[ Applause ]
>> Good afternoon.
My name is Phillipe Hausler, and
I'm here today, with my
colleague, Donna Tom.
And we're going to talk about
Efficient Interaction with
Frameworks.
Now, we all care very deeply
about performance.
We want our laptops to be fast.
We want our phones and tablets
to have all day battery life.
And we want to do amazing things
with our desktops.
As a matter of fact, all of
these devices should have great
performance.
And it's our jobs to be able to
make that happen.
Now, performance has many
dimensions.
How fast code can run, how much
power it takes.
Or what the memory footprint of
that is.
Since, there are multiple
dimensions, how can we visualize
this a little bit better?
To give you a framework, no pun
intended, for visualizing this.
You can think of it as a graph
with the size of the data that
you're working with on one axis
and the frequency on another.
If you're looking at a lot of
data and code that runs very
frequently, you're going to be
up there in that first quadrant.
And these are going to be things
that are going to be likely to
be able to make a notable impact
upon performance.
And you're going to want to
spend time optimizing these
cases.
But if you're looking at
something that works with just a
little bit of data and runs just
a few times.
You're going to be down there in
that third quadrant.
And to be honest, you really
don't want to spend a whole lot
of time worrying about them, too
much.
It's that second and fourth
quadrant that are a bit
trickier.
These are gray areas that are
highly dependent upon the
situation.
And in these cases, you'll most
certainly want to be able to
measure the performance in a
scenario that reflects actual
usage.
And then, use that information
to be able to evaluate whether
it's worth your time to be able
to make changes.
In this release, we took a deep
look to be able to understand
how we could make performance
better across the operating
system.
But for your apps, as well.
We will go over a few really
awesome changes that we made in
Foundation.
And of course, Swift has been a
big part of this release, as we
took a long hard look at how
bridging works for some of the
Foundation types.
To be able to make them faster
and work better in your
applications.
Now, strings are, of course, are
a huge part of many apps.
They're used as tokens, human
readable data formats, and
displaying to the screen.
And efficient string handling
makes a big impact on many
applications.
And often is a huge part of the
critical content being displayed
to users.
But of course, the reason why
you are here, is you want to
make your app run faster.
You want to use less energy.
You want to get more things done
with less RAM.
And don't worry, we'll get to
that on each of the sections
that we're going to be talking,
today, about.
To give you things to keep in
mind when optimizing for
performance.
Now, as I said, we made a number
of performance improvements
across the operating system.
And in Foundation, we made some
pretty nice changes.
These are just a few of the
highlights.
We overhauled NSCalendar for
date enumeration, not only to
use less memory, but also, it's
much faster, too.
And trust me when I say,
calendrical calculations are
really tricky to get right.
And then, this update, the
NSCalendar implementation is not
only faster, but also, corrects
some outstanding Edge cases that
have been lurking around for a
while, now.
But when making changes, you
have to consider the scale at
which that change will impact.
And in Foundation and Core
Foundation, we took a number of
places where the small things
that would add up.
And we looked at a deep dive of
how thread-safe operations in
Foundation work.
And decided to migrate to using
Atomics and OS and Fairlock,
which in the end, ends up
playing a lot better with
quality of service.
Now, speaking of quality of
service, NSOperation and
OperationQueue have been also
overhauled to have more correct
implementation, whenever it
comes to their quality of
service.
You'll see some pretty neat
performance improvements, as
well.
And in heavy cases, we've seen
up to 25% improvement on
queueing operations, just to
point out one highlight.
And after working for a while,
now, in Swift, we realized that
copy on write is pretty
fantastic.
And in Foundation, a number of
the collection types will now
use copy on write as their
backing storage.
So, what's this whole copy on
write thing?
Copy on write is a mechanism, or
COW for short, where two items
can point to a shared backing
store until a mutation occurs.
And when that mutation happens,
the mutating party copies that
backing storage to be able to
allow for the write to happen.
So, in short, copying isn't
costly, anymore.
This means that whenever you
defensively copy a mutable
container, it's almost free.
And before, copies of
collections were at best, linear
execution time.
And now, whenever you copy them,
they're constant until a shared
mutation.
So, let's pull that apart a
little bit and understand how
it's working, under the hood.
So, in this particular example,
we're creating a new mutable
array.
And when this happens, we
initially have a COW backing
store that holds zero items.
So, we do some extra work and in
our application, we then call
copy.
In this particular case, we're
assigning B as a copy of A.
And whenever that copy has
occurred, the only price that
you pay in your application is
the allocation of the new
collection.
You don't have to actually copy
any of the items.
So, in this case, we're still
pointing to the same backing
store that holds zero items.
So, later on, if we were to make
a mutation, then what will
happen is that the copying party
initially has a reference to
that shared backing store.
So, in order to make a mutation,
it has to copy from that backing
store to be able to make sure
that the mutation is in safe.
But you have to take in
consideration that most
applications are going to be
ending at that point, right
there, whenever you don't have
any further mutations.
So, as you can see, you can end
up having a vast performance
improvement by leveraging this
feature.
Now, let's see how you can
actually use this in your
application.
Now, I'm as guilty as the next
developer.
I've written code like this with
comments, with the hopes that my
colleagues are going to follow
my suggestion, all in the name
of performance.
But there's a little pitfall,
here that if a mutable array
were to have snuck in, then we
would end up sharing mutable
state.
Which means we are going to be
sharing bugs.
Nobody wants that.
But since copies are nearly
free, now, we can do the same
thing every single time and not
have to worry about the
performance hit.
It's pretty great.
But it isn't just the copy
nature of properties.
Many times, mutable containers
are used to build things up.
And in this sample, the author
knew that NSMutableArray is a
subclass of an NSArray.
And the advertised return value
is an NSArray.
So, it's mostly safe, right?
Well, unfortunately, there's
some other consequences that can
happen, here.
If somebody checks the actual
class of the return type, well,
oops.
They could end up having a
mutation of shared state, again.
So instead, you can defensively
copy return values so that it
does the right thing without
having to worry about the
performance costs.
There's actually another case
that's a little bit more hidden.
In the case of Swift, whenever
either of these two APIs were
exported, we have to make a copy
to be able to preserve value
types.
And so, if you cast to an array
of any, from the NSArray for
either of these two APIs, the
previous implementation would
have to spend a linear execution
time to be able to make that
copy.
If you defensively do so, the
copy then, doesn't end up
attributing to some other place
that is unknown performance
costs.
In Swift 3, we introduced a
number of structural types for
Foundation.
One that made a whole lot of
sense was NSData being bridged
to the structural type data.
And we took a long look at data
to be able to understand common
use cases and places that we
could improve data to be able to
make it work better in our
applications.
And in this release, we've got
now data is its own slice type.
And we've looked at the
performance for being able to do
common tasks like for example,
getting the Count of the data.
Or indexing to a specific byte
at an offset.
And some of these
implementations are kind of
extreme.
Normally a few machine
instructions wouldn't move the
needle, at all.
But what it comes to
representing a byte buffer, even
20 versus four instructions can
actually make a difference.
So, this code looks pretty
simple.
But if has a few interesting
characteristics that reveal some
insight on how we could make
data faster.
First off, data is a collection,
just like array.
It can be subscripted, but both
indexes and ranges.
So, this means that the start
index of the data, is not always
zero.
Because the index is similar to
iterators in the other
languages.
And for the record, this code
has nothing wrong with it.
We just used it to be able to
understand what parts of data
should be refined.
So, the two questions, here, are
how big is the data that we're
dealing with?
And how many times it's called?
Where is it on that chart?
And the answer truly is that it
could fall on almost any of
them.
And most likely, it's in that
place where it needs to be
measured.
So, we did exactly that.
And on the top in the blue, is
the initial Swift 3 version of
Data.
And when subscripting, it took
about 16 nanoseconds on the
machine that I was using to be
able to profile it.
And since data is a common
currency of dealing with a
collection of bytes, this should
be really, really fast.
After tuning, we got it just
down to four nanoseconds.
It's pretty impressive.
And if you were using Data,
before, you get this advantage
for free.
And it will also be able to
interoperate with all the rest
of the APIs that take and use
data.
Thanks.
[ Applause ]
Now again, preface, here for
you, none of these examples are
clearly wrong or harmful.
But they do have things to be
able to consider versus their
counterparts.
Oftentimes, it's viewed that a
collection of bytes can be
expressed in an array.
And in small cases, sure.
That works just fine.
However, there's a hidden cost,
here, from a cognitive sense
that when you try to write it to
a file, that' pretty tricky.
There's a lot of Edge cases,
there.
We take care of that for you.
Being able to interoperate with
things like writing to files,
converting to basic C4, Data is
a clear winner.
Now, sometimes we get nostalgic
and we fall back to old trusty
malloc.
And unfortunately, this can
sometimes skip out on other
optimizations.
Like for example, knowing proper
allocation sizes that work best
with rounding to the right
regions that malloc returns for
buffers.
Data deals with all of this, for
you.
So, you don't have to worry
about reallocation.
You don't have to worry about
understanding the Edge cases of
what sizes might be better for
malloc, than others.
Now, these two next lines are
really similar.
And they're worth noting,
because in certain cases, you
want to be able to work with a
large region of data.
And in other cases, you want to
be able to just hold around a
small little bit of it.
So, Data has two APIs.
One of which is subdata in
range.
And this will create a copy, so
that if you have a large file
that you're working with, but
only want to keep around a small
bit.
Subdata with range will make an
enforced copy, like that.
But we changed Data so that it's
its own subtype, or sub-slice of
a type.
So, that whenever you use the
range syntax, even for example,
this version of ranges.
You can use that as a window to
be able to peer into the data.
So, if you have a large file
that you're dealing with, that
you just need to be able to
parse it and the data itself
will only be transitory.
Then, using slices is an
incredibly efficient manner to
be able to access it, because it
causes no copy.
Now, we've talked a number of
times about bridges.
And there are two types of
bridges that are relevant, here.
And on the left we have
toll-free bridging.
And in these cases, they are
bridging from a Foundation type
to a Core Foundation type.
Or from a Foundation type to a
Core Foundation type.
And these are zero cost at the
cast.
So, whatever you actually have
in this particular case, the
NSArray being bridged to a
CFArray, it's just a
reinterpretation of a pointer.
But there is a slight cost to be
paid, whenever you pass that
object to CFArrayGetCount,
there's something that you have,
there.
We'll go over that, here in just
a little bit.
So, contrasting that to Swift
bridging, those are cases where
you're bridging from a reference
type to a structural type.
And contrarily so, bridging from
a structural type to a reference
type.
But the costs in these
particular cases are paid in
advance.
So, whenever you import from
Objective-C or if, in this case,
you use as question mark, to be
able to convert between the two,
you are paying that cost, there.
But the differential is that
these are then normal costs at
the usage.
So, let's dive in a little bit
more.
I know this looks scary.
Don't have a cow, actually, as a
matter of fact, this doesn't
actually.
CFArray doesn't implement copy
on write.
But whenever you pass an NSArray
or subclass into
CFArrayGetCount, it will
magically call out to this
Objective-C method count.
So, let's pick it apart a little
bit further and understand how
this is different than the Swift
bridge.
Here it is, a little bit more
simplified.
First, we tested the arrays and
Objective-C subclass.
And then, we see that invocation
to count, there.
If it wasn't, we know that the
structural layout of the object
can let us indirect to that
variable count.
So, expanding it a bit further.
It checks the internal layout of
the object against the expected
class table.
So, in truth it basically boils
down to costing two indirections
and a function call, to
determine if the Objective-C
method needs to actually be
invoked or not.
So, let's wrap it up for this
one.
Casting to an array or subclass
to a CFArray is just a
reinterpretation of the pointer.
It's the usage points that
actually have the cost.
So, this is usually an
exceedingly small impact.
But in rare cases, it could
often move the needle a little
bit.
So, on the graph, we're mostly
down there in that third
quadrant, maybe peeking up a
little bit.
Now, on the flipside, we have
Swift bridging.
Now, remember this is whenever
we call as question mark or
expose an API from Objective-C,
whenever we have a bridged
reference type.
The compiler will emit this
bridgeable family of functions,
in which will in turn in this
particular case, invoke the
referencing initializer for
Data.
And when Data is initialized
with a reference it will make a
copy to store into the backing
storage of the data.
Because we need to be able to
preserve, not only the value
type nature of the data.
But also, make sure that we
aren't holding onto a shared
mutable reference, causing of
course, bugs.
So, you can see that if this
were actually a mutable case or
a proxy or some other subclass,
it could be a potentially costly
point under the hood.
Now, bringing it all back
together, let's look at that
graph, again.
And in this time, the bridge is
not too often hit.
And whenever the common case,
the copy is optimized into a
retain.
So, we're going to, again, be
down there in that third
quadrant.
But in the cases of the
exceptions for subclasses, like
for example, mutable data, that
copy could potentially be in any
of those quadrants.
So, if you have subclasses that
you need to be able to deal
with, or you're passing mutable
versions back and forth across
the bridge.
You should probably be
understanding those with better
measurements with useful cases.
But this same pattern occurs for
not just data, but all of the
structural types within Swift.
Things like arrays and
dictionaries and strings.
Now, speaking of strings, I
heard they're kind of popular.
Here to guide you through the
wonderful world of strings,
ranges, and texts is Donna.
[ Applause ]
>> Thanks, Phillipe.
Now, strings are probably one of
the most frequently used data
types, ever.
If you're an app developer, your
app probably creates and mutates
hundreds, if not thousands, of
strings each time they're used.
And if you're a framework
developer, your framework's
probably create and mutate
strings each time someone calls
one of our APIs.
And those strings might then be
mutated farther beyond the
boundaries of your framework.
And strings, they're not used in
a vacuum.
You're interacting with
frameworks to do anything
interesting with strings.
Whether it's slicing them,
dicing them, smashing them
together.
Or even just rendering them on
the screen.
And so, you may be able to
improve your app or framework's
performance by understanding how
strings, ranges, and text
interact with frameworks.
And by making implementation
choices based on this
understanding.
But before we dive into the
nitty gritty details, I'm going
to kind of go back to rehash
some of what Phillipe talked
about and talk a little bit
about evaluating the impact of
performance improvements.
Now, it's really important not
to lose sight of the big picture
when you're looking to improve
performance.
It's really easy to get caught
up in the details and become
really focused on optimizing for
those very particular scenarios.
But it those scenarios don't
reflect the way users actually
use your app framework, then
it's not a very efficient use of
your time to optimize for them.
And so, once you've decided that
a scenario you're looking at
reflects actual usage, you might
then look at the performance of
a particular piece of code.
And when you do that, it's
important to keep in mind, these
concepts that we've discussed.
How big is the data I'm working
with?
And how often is that code
running?
And so, we're going to bring
back the graph.
But we're going to change the
axis labels a little bit for the
context of strings and text.
So, the general concept is the
same.
But for strings, we'll think of
it in terms of how long or how
short the string is and how
frequently that code is running.
So, let's keep these concepts of
scale and frequency in mind as
we cover these topics.
First, we're going to start with
string bridging.
And then next, we'll talk about
ranges and the nuances of string
index.
And finally, we'll share a few
tips for working efficiently
with text layout and rendering
in AVKit and UIKit.
So, let's get started with sting
bridging.
The first example we'll look at
works with UILabel.
So, let's say I have a label
like this, and I want to access
its text.
In Swift, I might start with
something like this.
But we asked the UIKit framework
to give us the label's text.
So, here's what the interface to
that looks like.
But remember, that this is just
a generated interface.
UILabel is implemented in
Objective-C.
And so, even though our variable
text is a Swift string, the
backing store is actually an
NSString and it's bridged from
Objective-C.
And so, now let's take a look at
what happens when we ask for
that label's text from Swift.
The NSString form the framework
is a reference type, while
Swift's string is a value type.
And so, when we ask the
framework for that NSString,
it's wrapped in the value type
when it crosses the Swift
bridge.
But we don't know what might
happen to that original NSString
after bridging.
And so, to preserve Swift value
semantics, the framework has to
make a copy of it.
Now luckily, in this case, the
original NSString is immutable.
And so, when the framework makes
that copy, it's optimized to
just retain, which is pretty
cheap.
Since, it's just incrementing
the ref count.
But even if we did make a full
copy of this string, let's go
back to our graph and evaluate
the impact.
Now in this case, the original
string consisted of seven ASCII
characters.
So, even if we made a full copy
the impact would be pretty
small.
Now, most of the time UILabels
are going to consist of short
strings that are used for UI
display purposes.
And so, you're probably not
going to be fetching their text
very frequently.
And in most cases, you'll end up
down her in quadrant three.
So, the bridging copies aren't
going to be a big deal.
But now, let's take a look at
what happens in a larger scale
example, like in NSText storage.
NSText storage is the
fundamental storage mechanism
behind TextKit.
It's used to power text views
like the one you see here, in
both Cocoa and Cocoa Touch.
And so, if you're working with
text views, you're going to want
to be able to access the text
inside that text storage.
And so, here's what that looks
like in Swift.
Here's the generated interface.
And here's the Objective-C
interface.
But notice here, the NSText
storage is a subclass of
NSMutableAttributedString.
Now, since NSText storage is
intended for working with text
editing, it's reasonable to
expect the contents of that text
storage to be mutated,
frequently.
And the contents of the text
storage could also be a very
long string.
It could be megabytes or even
gigabytes in size.
And so, for efficiency, the
framework only keeps the mutable
string around.
So, when you ask for that string
property on the text storage,
what you'll get is going to be
backed by an NSString that
refers to the mutable string.
And so now, once again, we'll
take a look at what happens when
we ask for that string property
from Swift.
Just as before, it'll be wrapped
in the value type when it
crosses the bridge, because it's
an NSString.
And the framework is going to
make a copy.
But unlike in the UILabel case,
here the underlying NSString is
actually mutable.
So, this copy could be
expensive.
And as we said previously, text
storage is much more likely to
contain long length strings.
It could be megabytes or even
gigabytes in size, so
potentially this copy could be
very expensive.
But now, let's take a look at
what happens when we ask for the
mutable string property.
NSMutableString is a reference
type that is not bridged.
And because it's not bridged,
there's no copy.
So, we avoid the cost of the
copy, here.
This situation results from a
mismatch between Swift's value
semantics and the design of
NSText storage, which needs to
use reference semantics for
performant management of large
amounts of text.
So, we're working on solving
this problem, here at Apple.
But we don't quite have the
solution, yet.
So, you should be aware that
this is something that can
happen.
And if you're working with very
large amounts of text and the
text storage, use MutableString
to access it, even if you don't
plan on mutating it.
But before you go bananas
changing all of your string
accesses to MutableString, let's
consider that graph, again.
Now, due to the nature of the
text storage API, you're
probably going to be up here on
the top half, in terms of
frequency.
So then, the real question
becomes, how much text do you
expect that storage to contain?
A kilobyte?
Might be in here, it's not too
bad.
If you use the string property,
that's probably fine.
One megabyte?
You're starting to move into
first quadrant territory, here.
And you may want to consider
using MutableString.
One gigabyte?
I really hope you're using
MutableString.
And as I said, we're working on
fixing this on our end, here.
So, keep an eye out for it in
future releases.
And so, now that we have a
better understanding of string
bridging, let's move on to
ranges.
Now, I don't know about the rest
of you, but this is certainly
how I feel when I have to work
with ranges and string index in
Swift.
And to see why, let's consider a
string containing the face palm
emoji, which coincidentally,
looks a little bit like me.
So, here's our string.
It's a length one in terms of
perceived characters.
But this one character consists
of three individual components.
We have this jaundice face palm,
a skin tone modifier, presumable
to get rid of the jaundice, and
a gender modifier.
But these visual components
don't tell the whole story,
either.
There are also, two control
characters in this string.
A zero width joiner and a
variation selector.
And to see this, we'll look at
the Unicode Scalar values that
make up the string.
Now, if you're not familiar with
the term, a Unicode Scalar value
is a 21-bit number that uniquely
represents a Unicode character.
And so, here are the Unicode
Scalar values that make up the
string, and the names that are
associated with those values.
So, if you look at the string
from a Unicode Scalar point of
view, it's actually made up of
five different values, and it
has length five.
Now, this is all fine and dandy
if you're working purely with
Swift's string API.
But if you're using
NSAttributedString, or any API
really, that uses NSRange, these
think in terms of UTF-16.
And so, if you look at the
UTF-16 view of this string, it
actually consists of seven
values and it's of length,
seven.
Now this can get really
confusing, and it makes working
with NSRange and range of string
index a little bit painful.
So, let's clear up some of this
confusion and talk about how to
work with NSAttributedString,
which makes heavy use of
NSRange.
So, let's say I have a string
like this.
And I want to create an
attributed string with it, and
change the background color of
one of the characters to green.
Now, this is complicated enough,
that even I forget how to do it,
sometimes.
But don't tell anyone.
So, I might have to look it up
on the internet.
And then, after I do that I
might end up with some code that
looks like this.
it's annoying, because I have to
keep flipping back and forth
between this string API and this
NSString API, right.
I have to take my original
string and then, create an
NSString from it, and then
calculate the NSRange using the
NSString.
But then, I have to go back and
create my
NSMutableAttributedString using
the original string, again.
Yuck. I don't like to do this.
Nobody likes to do this.
The good news is that you won't
have to do this, anymore,
because in Swift 4, we're
introducing new initializers for
NSRange and Range.
And so, when we use these new
initializers.
Thank you.
That same example trims down to
just this and it's a lot easier
to read, write, and remember.
So, the new NSRange initializer
that's being used here, it takes
a range and the Swift string and
it uses it to create the
NSRange.
And you can just pass that
directly into the
attributedString API.
But now, let's take a look at
the conversion in the other
direction from NSRange to Range
and string index.
To look at this simple example,
let's say we have some html like
this, and we want to print out
all the start tags.
And so, in order to do this,
we'll use NSRegularExpression to
find the tags we want, and then
append them to a string.
Sounds reasonable, right?
But the NSRegularExpression API
gives me NS ranges back from my
match groups.
And I need ranges of string
index to be able to append to my
Swift string.
And so, before these new
initializers were available, we
might have use something like
this to convert from NSRange to
range a string index.
And remember that face palm
emoji we talked about a few
minutes ago, and how it was of
length seven, in terms of
UTF-16?
And length five in terms of
Unicode Scalar?
Well, this code is a little bit
complicated, because it's doing
that conversion from UTF-16 to
Unicode Scalar.
But now, with these new array
initializers, you don't have to
do that anymore, either.
We can just take the NSRange we
get back from the match group
and use that to create our range
of string index, and append it
directly to our string.
This is a lot more convenient
and it's a lot easier to use.
So, these new initializers are
really great, and I hope that
you use them for all your Range
and NSRange conversions.
[ Applause ]
Thank you.
[ Applause ]
So, that wraps up ranges.
Let's move on to text layout and
rendering.
Text is hard.
It seems simple on the surface.
Because everyone knows what text
is.
Everyone encounters it on a
daily basis.
It's familiar and it's ordinary.
And as a result, there is a
tendency to implicitly assume
that it's easy.
But it's not easy.
Text poses some real performance
challenges, because of its
ubiquity in scale.
So, think about this.
We ship 40 localizations for
iOS, 35 for macOS, 39 for
watchOS, and 40 again for tvOS.
And for all of these platforms,
we support text input for more
than 300 other languages.
And each of these languages may
have different rules for things
like word breaking and
hyphenation.
And that's going to affect the
line breaking, which is going to
affect the text layout, which is
going to affect the text
rendering.
And our frameworks need to be
able to handle all of these
languages, correctly.
Now, if that wasn't enough, here
are just some of the other
factors that our frameworks take
into account when we perform
text layout and rendering.
So, we look at all of these
things and more to render your
text in a way that's both
correct and performant.
So, I encourage you to use the
standard label controls whenever
possible.
Now, with so many different
variables to consider, our
frameworks use multiple
optimization strategies, under
the hood.
Selection of any one particular
strategy is highly situational
and multiple criteria might have
to be met in order to apply one.
And so, I would warn you to be
careful when you're applying
your own optimizations on top of
the standard controls.
Because a change in rendering
conditions or input data could
nullify any performance gains
from your optimizations.
And to illustrate what I mean by
that, I'd like to share with you
a cautionary tale of two labels.
So, once upon a time, there was
a developer who needed to render
a lot of labels in her app.
And she required each label to
have a line of bold text,
followed by a line of normal
weight text.
And she needed to position her
labels by manually setting their
frames, because business
reasons.
So, she set up her labels with
attributed strings and off she
went.
But she noticed that the
scrolling performance in her app
was a little bit slower than she
would like.
So, she did a little bit of
profiling and she found that one
areas where a lot of time was
being spent was in laying out
and rendering the labels.
So, then she did some
experimentation and she noticed
that if she rendered each line
in a separate label, her app
scrolling performance improved.
''Well, this is fantastic'', she
thought.
So, she changed her app to use a
separate label for each line of
text.
And she lived happily ever
after, until her company wanted
to expand into the Chinese
market.
When she tested her app with
this Chinese text, she was
dismayed to discover that the
scrolling performance was even
slower than before.
So, what happened, here?
Well, our tragic heroine started
off with the right approach.
She was looking at frequent
rendering of lots of short
strings, which falls here, in
quadrant two.
And so, she took some
measurements, she determined an
area for improvement, and she
made an optimization.
But then, when the input data
changed to Chinese text, the
optimization was no longer an
improvement.
And to see why, let's do a
postmortem.
So, in this example, the initial
conditions qualified the
attributed strings for a faster
rendering path within the
framework.
And the optimization of
splitting each line into its own
label took advantage of the fact
that attributed strings
containing only one style of
text may qualify for faster
rendering.
But this isn't a sufficient
condition for faster rendering.
The faster rendering paths take
shortcuts that make certain
assumptions about the input data
and the rendering conditions.
And in this case, using Chinese
text requires font fallback, and
that forced the rendering down
the slower path within the
framework to maintain
correctness.
And on top of that, splitting
the two-line strings into
separate labels, meant that the
app was rendering twice as many
labels as it needed to.
And additionally, the app was
using older layout practices by
manually setting the frames,
instead of using auto layout.
So generally, we're going to pay
a lot of attention to
performance under conditions
that are using modern practices,
like auto layout.
Because that's what most apps
are using and that's where our
performance improvements will
make the largest impact.
So, with auto layout in
particular, that text system
caches some layout information.
And this can really improve
performance.
But since this app wasn't using
auto layout, it couldn't take
advantage of that.
And so, with that in mind,
here's some strategies and tips
that you can employ to improve
text layout and rendering
performance in your app.
Now, if you've been paying
attention, you already know what
I'm going to say the first
strategy is.
Use the standard labels for
rendering your text and let us
do the heavy lifting for you.
The framework is in a better
place to apply these
optimizations, because it has a
bigger picture view of the
situation and more information
about the rendering conditions.
And when we make performance
improvements, you'll
automatically get those
benefits.
So, as an example of that, in
macOS 10.13, NSTextField renders
text roughly three times faster,
at 5.7 milliseconds per frame
during live resize.
Down from 16.67 milliseconds per
frame in 10.12.
And you'll get this performance
boost for free if you're using
the standard framework controls.
So, it's really a good idea to
use the standard controls
whenever possible.
Second strategy, as we kind of
saw from out story, is to use
modern layout practices like
auto layout.
Now, text layout and rendering
performance with modern
practices is very heavily
scrutinized on our end.
And by adopting these modern
practices, you'll be less likely
to run into edge case
performance scenarios that we
haven't already seen and
improved.
Next up, is a lower level tip.
If you're working with
NSAttributedString, there are a
few attributes that are
absolutely necessary for layout
and rendering.
And if you don't supply these
attributes yourself, the text
system needs to resolve them in
order to be able to render.
And so, you can shave off a
little bit of time by supplying
these attributes yourself, when
rendering attributed strings.
In a similar vein, you might see
some small improvements from
explicitly specifying the
writing direction and alignment,
instead of using the natural
settings.
And this will save you a little
time, because the text system
can skip over any logic that
tries to figure out the writing
direction and the alignment.
But remember that you'll only
want to do this if you're
absolutely sure that your input
data won't contain mixed writing
directions.
Now, there's a balance between
performance and correctness.
And this is one optimization
that can tip the balance a
little too far away from
correctness if you're not sure
of your input.
And along those same lines of
performance versus correctness,
if you know that all your labels
are only going to consist of one
line, you can set the line break
mode to use clipping.
Now, by default, labels will use
word wrap.
And when you do this, the text
system needs to figure out where
to place the line breaks.
And so, if you use the clipping
line break mode, you can skip
this line breaking and
hyphenation logic, and your text
might run there just a little
bit faster.
So, in summary, we've looked at
a lot of different things,
today.
From performance improvements in
Foundation, to string bridging
and working with text.
Now, if you take just one thing
away from this talk, let it be
this graph.
Use the concepts of scale and
frequency to minimize the large
expense of operations in your
code.
Don't sweat the small infrequent
stuff, and always measure if you
aren't sure.
So, for more information, you
can visit our session URL, we
are Session 244.
And check out these related
sessions on video.
Pretty cool.
Unfortunately, most of them
already happened.
Thank you, and enjoy the rest of
the conference.
[ Applause ]