{"id":20842,"date":"2018-03-09T11:52:07","date_gmt":"2018-03-09T16:52:07","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=20842"},"modified":"2018-03-10T14:06:35","modified_gmt":"2018-03-10T19:06:35","slug":"faster-swift-string-concatenation","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2018\/03\/09\/faster-swift-string-concatenation\/","title":{"rendered":"Faster Swift String Concatenation"},"content":{"rendered":"

Nick Lockwood<\/a>:<\/p>\n

I’m sure I heard somewhere that \"\\(foo)\\(bar)\"<\/code> is the recommended way to do string concatenation in Swift, but I benchmarked it and it’s almost 100x slower than using +<\/code> or String.append()<\/code>.<\/p><\/blockquote>\n

I know I’ve heard that as well. I assumed it was taken as a hint to figure out the proper allocation size up front. But currently it’s slower because the interpolated elements are not assumed to be strings.<\/p>\n\n

Joe Groff<\/a>:<\/p>\n

\n

Yeah, \\(x)<\/code> goes through the print-anything path for x<\/code>, which hasn’t really been optimized<\/p>\n<\/blockquote>\n\n

Steve Barnegren<\/a>:<\/p>\n

\n

I thought that the recommendation to use \"\\(foo)\\(bar)\"<\/code> over +<\/code> was more for compilation performance than runtime performance, as the compiler has to work to understand which +<\/code> operator to use.<\/p>\n<\/blockquote>\n\n

Joey Devilla<\/a>:<\/p>\n

Running on the phone, the +<\/code> method is almost 70 times faster, which is a significant difference when concatenating a large number — 100 million — strings. If you’re concatenating far fewer strings, your better bet is to go with the option that gives you the more readable, editable code.<\/p><\/blockquote>\n\n

Marcel Weiher<\/a>:<\/p>\n

\n

A factor 100 here, a factor 100 there, soon enough… ¯\\_(ツ)_\/¯<\/p>\n<\/blockquote>\n\n

Nick Lockwood<\/a>:<\/p>\n

\n

A lot of people have jumped on this to criticise Swift’s maturity as a language.<\/p>\n

To put it in context, even at 100x slower, you can still comfortably perform 500,000 string concatenations per second. In most apps this would be a complete non-issue.<\/p>\n<\/blockquote>\n\n

Update (2018-03-10): Nick Lockwood<\/a>:<\/p>\n

Deleted this, since it was due to a misconception on my part.<\/p><\/blockquote>\n

His original test<\/a> measured foo = \"\\(foo)bar\"<\/code> vs. foo += \"bar\"<\/code>, which is not what I would have expected from the tweet’s description. The latter is 100x faster because Swift is able to mutate the string rather than create a new one. The benchmark code is here<\/a>.<\/p>\n

I measured baz = \"\\(foo)\\(bar)\"<\/code> vs. baz = foo + bar<\/code>, which is what I thought he was originally talking about (i.e not building up a giant string), and found the latter to be about twice as fast, perhaps because of the overhead that Groff mentioned.<\/p>\n

Devilla measured newString = \"\\(string1) \\(string2)\"<\/code> vs. newString = string1 + \" \" + string2<\/code> and found the latter to be 70x faster. I tried to reproduce this but found less than 10% difference in the opposite direction<\/em>. In other words, interpolation was slightly faster. However, I am using Swift 4, and he was using Swift 2.<\/p>","protected":false},"excerpt":{"rendered":"

Nick Lockwood: I’m sure I heard somewhere that \"\\(foo)\\(bar)\" is the recommended way to do string concatenation in Swift, but I benchmarked it and it’s almost 100x slower than using + or String.append(). I know I’ve heard that as well. I assumed it was taken as a hint to figure out the proper allocation size […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"","apple_news_api_id":"","apple_news_api_modified_at":"","apple_news_api_revision":"","apple_news_api_share_url":"","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[],"tags":[138,71,901],"class_list":["post-20842","post","type-post","status-publish","format-standard","hentry","tag-optimization","tag-programming","tag-swift-programming-language"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/20842","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=20842"}],"version-history":[{"count":5,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/20842\/revisions"}],"predecessor-version":[{"id":20852,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/20842\/revisions\/20852"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=20842"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=20842"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=20842"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}