lvnyk / BezierString

Rendering NSAttributedStrings along arbitrary UIBezierPaths
MIT License
195 stars 16 forks source link

Swift 4, Xcode 9 struggles badly to compile #5

Open SuperWomble opened 6 years ago

SuperWomble commented 6 years ago

Hi! Firstly, thanks for the project. It's very helpful.

I've been running the code using the long expressions flag, to check where Swift is dying in my code, and it's flagged BezierString, due to the use of multiple-statements on one line.

Some of the lines in Geometry.swift take up to 6 seconds to compile on a 2015 MBP, using Xcode 9 GM.

e.g.

let y: CGFloat = CGFloat(CGFloat(CGFloat(p1.x * p2.y) - CGFloat(p1.y * p2.x)) * CGFloat(p3.y - p4.y) - CGFloat(p1.y - p2.y) * CGFloat(CGFloat(p3.x * p4.y) - CGFloat(p3.y * p4.x))) / CGFloat(CGFloat(p1.x - p2.x) * CGFloat(p3.y - p4.y) - CGFloat(p1.y - p2.y) * CGFloat(p3.x - p4.x))

By separating these out in to their own statements, compiling returns to usual speeds. I'd post the code here, but my code separation is terrible: I don't really know what the code is doing so my naming is random.

For the flag, see:

https://www.jessesquires.com/blog/measuring-compile-times-xcode9/

Cheers.

lvnyk commented 6 years ago

Hey,

I believe everything past the line 80 in Geometry.swift is redundant for the purposes of this particular project, the only thing needed are operators on CGPoint. All of the rest are convenience functions I use elsewhere and can be removed.

The long lines that are slow to compile are basically a workaround so that the previous compiler got enough hints that a result was a CGFloat and it compiled at all. Now all of that has been turned on it's head, and all the CGFloat casts are causing the slowdowns. Simply removing the casts should help. I'll be updating the project the latest syntax and cleaning it up soon.

Best

SuperWomble commented 6 years ago

Cheers!