Make compilation 2x faster by using literals

[kkebo]

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]

All committers have signed the CLA.

[youming-lin]

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]

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]

@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]

@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]

Also, please rebase if you can.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
149 Code Smells

No Coverage information
0.0% Duplication

[kkebo]

@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?

[kkebo]

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]

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]

@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]

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

[dannys42]

@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]

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.