Conversation
|
Another example, much simpler takes 3600ms. |
|
After migrating most of the code in one of our apps over to the new syntax the build time has been halved (from about 5 min to 2.5). All of our view constraints all run in a few milliseconds where most were in the hundreds, if not thousands. Strongly recommend the core team looks over this issue and applies some (maybe not my) solution. Thanks for a great library! |
|
Always felt it was due to something like this. It's a pity. But the |
|
Is it this a semver break? |
|
@orta technically no, but it's adding to the API and suggesting a new API so "perhaps"? With the current iteration I'm not replacing the current operators, I've only copied or "aliased" them (hence non-DRY). Was hoping to spark a discussion on how this would be best implemented upstream. I'm willing to take lead on any required changes. |
|
I'm basically the person running this repo, but I've never used it, nor really grok it's trade-offs as I've been absent from Swift for enough years. So I'm happy to go with consensus, and those compilation speed improvements make any pain worth it IMO - it's bad enough without a library making it worse. Did tests pass for you locally? Do we need to update travis? |
|
Is there an ETA for this fix to be merge ? |
|
No ETA, maybe a rebase might fix CI though |
shaves around 10 seconds in build time (see robb/Cartography/pull/293)
Addresses #215.
This is maybe not the best solution (not DRY) but with the code below we've seen swift type checking times go down from 8800ms+ to 39ms (example at bottom).
With this PR I wanted to start a discussion around using custom operators. As I understand it, the problem is the overloading of common operators like
==,-and+causing confusion for the type checker and massive compile times.Other than tests, not sure what is missing but I'd be happy to make any improvements.
Example code
A fairly complex example, here seen with the updated syntax.