Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make compilation 2x faster by using literals #65

Merged
merged 2 commits into from
Mar 29, 2022

Conversation

kkebo
Copy link
Contributor

@kkebo kkebo commented Mar 17, 2022

Description

I replaced Character(Unicode.Scalar(...)!) by "\u{...}". This makes compilation almost 2x faster.

Here is the benchmark:

branch command 1st execution time 2nd execution time 3rd execution time average
master swift build 4.37s 3.65s 3.52s 3.85s
replace-by-literal swift build 2.11s 2.17s 2.11s 2.13s
master swift build -c release 9.81s 9.37s 9.67s 9.62s
replace-by-literal swift build -c release 5.04s 5.11s 5.02s 5.06s

(Mac mini (M1, 2020) 8GB RAM, macOS 12.3, Xcode 13.3, Swift 5.6)

Motivation and Context

My changes can reduce compile time without changing any functionality.

Not only that, these can also resolve issues like kkebo/DevToys.swiftpm#6 (comment).

How Has This Been Tested?

Checklist:

  • I have submitted a CLA form
  • If applicable, I have updated the documentation accordingly.
  • If applicable, I have added tests to cover my changes.

@CLAassistant
Copy link

CLAassistant commented Mar 17, 2022

CLA assistant check
All committers have signed the CLA.

@youming-lin
Copy link
Collaborator

This looks like a complete revert of #51 minus changes in two lines of comments.
LGTM since I originally wrote this using literals, but according to the thread in #51 the bug in Swift wasn't fixed until 5.1 so this change will break for users on 5.0.

I don't work on this project any more so I'll defer to @dannys42 to decide if 5.0 support is still needed.

@dannys42
Copy link
Contributor

Thanks @KKK669 for the submission and @youming-lin for the context. I've been slowly phasing out Swift 5.0 and 5.1 from the various Kitura projects. My typical approach has been to bump the major version of the project while simultaneously dropping support for older versions of Swift and updating the CI build. So let me take a stab at that then revisit this.

I'll try to address this as soon as I can. But I apologize right now if I don't get to this soon, I'm a bit overloaded right now. Feel free to ping a reminder to me if I'm taking too long.

@kkebo
Copy link
Contributor Author

kkebo commented Mar 18, 2022

@youming-lin Thank you for sharing the related issue. I also replaced Character(Scalar(...)!) in the comments. 6d490b0

@dannys42 Thank you for sharing the future plan. I'm going to wait until then.

@dannys42
Copy link
Contributor

dannys42 commented Mar 25, 2022

@KKK669 I see one difference on line 457 from your changes vs @youming-lin's on the last character of the line. Can you confirm what the correct value should be?

< +    "nless;":"\u{226E}","nLl;":"\u{22D8}\u{338}","nlsim;":"\u{2274}","nLt;":"\u{226A}\u{20D2}",
---
> +    "nless;":"\u{226E}","nLl;":"\u{22D8}\u{338}","nlsim;":"\u{2274}","nLt;":"\u{226A}\u{338}",
                                                                                                                                                     

@dannys42
Copy link
Contributor

Also, please rebase if you can.

@kkebo kkebo force-pushed the replace-by-literal branch from 6d490b0 to 4348a95 Compare March 25, 2022 18:36
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 149 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@kkebo
Copy link
Contributor Author

kkebo commented Mar 25, 2022

@dannys42

I rebased now.

@KKK669 I see one difference on line 457 from your changes vs @youming-lin's on the last character of the line. Can you confirm what the correct value should be?

It seems that the value of nLt; has been changed from \u{226A}\u{20D2} to \u{226A}\u{338} in #51. Is this a mistake of #51?

34B49DB6-47D7-4A27-A75A-6D5F159EB1E4

@kkebo
Copy link
Contributor Author

kkebo commented Mar 25, 2022

I think the values should be left as they are even if it is an incorrect value. By doing so, this PR becomes a simple conversion-only difference.

If \u{338} is incorrect, we should correct it in another PR.

@youming-lin
Copy link
Collaborator

I originally generated the maps from a JSON file I found that maps the named character references to unicodes, e.g. https://html.spec.whatwg.org/entities.json

I would doublecheck the spec to make sure the unicodes are correct.

@kkebo
Copy link
Contributor Author

kkebo commented Mar 25, 2022

@youming-lin Thank you for sharing the specs. I checked it and I confirmed that #51's change was incorrect. However, I haven't made any changes to that part in this PR, so if I fix it here, I think it would be out of line with the purpose of this PR.

@dannys42
Copy link
Contributor

@KKK669 Sounds good. That's for your PR and all the research!

@dannys42 dannys42 mentioned this pull request Mar 29, 2022
@dannys42 dannys42 merged commit c475717 into Kitura:master Mar 29, 2022
@dannys42
Copy link
Contributor

@KKK669 I pushed your changes and made a release for 4.0.1. I also added an issue to track the unicode bug. Please feel free to add any context you think is necessary for that issue. Or submit a new PR if you're inclined. :-)

There's an issue with cocoapods so I can't push an updated pod right now. I'll try again later.

@kkebo
Copy link
Contributor Author

kkebo commented Mar 29, 2022

Thank you so much! I will send a PR for #67 when I have time. But if someone else sends a PR earlier than me, I don’t mind.

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

Successfully merging this pull request may close these issues.

5 participants