Skip to content

[benchmark] Add dataUsingUTF8Encoding() #22648

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

Merged
merged 4 commits into from
Feb 20, 2019

Conversation

ianpartridge
Copy link
Contributor

Currently there is no microbench for string.data(using: .utf8).

However, there is a microbench which covers creating a Data from a String via Data(string.utf8).

It is worth having a separate bench for string.data(using: .utf8) because it currently bridges via NSString whereas Data(string.utf8) does not.

Add a benchmark for string.data(using: .utf8) so future improvements to its performance can be measured.

CC: @milseman @itaiferber @Catfish-Man

@ianpartridge
Copy link
Contributor Author

@palimondo - I've updated as per feedback.

Please could someone run CI testing?

@itaiferber
Copy link
Contributor

@swift-ci Please smoke test

Copy link
Contributor

@itaiferber itaiferber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest changes LGTM

@palimondo
Copy link
Contributor

@swift-ci please benchmark

@ianpartridge ianpartridge changed the title [benchmark] Add StringToDataUsingUTF8Encoding [benchmark] Add dataUsingUTF8Encoding() Feb 15, 2019
@swift-ci

This comment has been minimized.

Copy link
Contributor

@palimondo palimondo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two more issues I've overlooked before:

  • new tests shouldn't use legacyFactor
  • benchmark reports shows there's memory leak, we should wrap that conversion in autoreleasepool

@palimondo
Copy link
Contributor

@milseman @itaiferber Any thoughts on the doubling of memory used between the runs with one and two iterations?
mem_pages [i1, i2]: min=[3299, 6662]

Is the use of @autoreleasepool required and expected, or is the "leak" a bug that needs to be reported?

@itaiferber
Copy link
Contributor

@palimondo This isn't a real leak: the result of .data(using:) is an autoreleased NSData object. Absent an autoreleasepool around the construction of the data, it's going to remain present in memory until the outermost autoreleasepool releases it, which in this case is likely past the lifetime of the test.

So wrapping this call up is entirely reasonable

palimondo and others added 2 commits February 18, 2019 09:34
Co-Authored-By: ianpartridge <i.partridge@uk.ibm.com>
@ianpartridge
Copy link
Contributor Author

@palimondo I have updated this PR as requested.

Please can someone re-run CI and merge as appropriate?

@palimondo
Copy link
Contributor

@swift-ci please benchmark

@palimondo
Copy link
Contributor

@swift-ci please smoke test

@swift-ci
Copy link
Contributor

Performance: -O

TEST OLD NEW DELTA RATIO
Regression
DataCreateEmpty 170 200 +17.6% 0.85x
DataCountSmall 22 25 +13.6% 0.88x
DataCountMedium 28 31 +10.7% 0.90x
Improvement
DataSubscriptSmall 31 28 -9.7% 1.11x (?)
FlattenListLoop 4332 3968 -8.4% 1.09x (?)
ObjectiveCBridgeStubFromNSDate 6190 5680 -8.2% 1.09x (?)
Array2D 7520 6912 -8.1% 1.09x
ObjectiveCBridgeStubNSDateRefAccess 400 371 -7.2% 1.08x (?)
FlattenListFlatMap 6557 6091 -7.1% 1.08x (?)
MapReduce 397 369 -7.1% 1.08x
MapReduceAnyCollection 398 370 -7.0% 1.08x
Added
String.data.Empty 91 100 94
String.data.LargeUnicode 537 548 542
String.data.Medium 435 438 437
String.data.Small 415 417 416

Code size: -O

TEST OLD NEW DELTA RATIO
Regression
DataBenchmarks.o 52228 54524 +4.4% 0.96x

Performance: -Osize

TEST OLD NEW DELTA RATIO
Regression
SetSubtractingInt25 102 112 +9.8% 0.91x (?)
SetSubtractingInt0 74 80 +8.1% 0.93x (?)
Improvement
DataCreateSmall 3450 3110 -9.9% 1.11x (?)
DictionaryBridgeToObjC_Access 995 925 -7.0% 1.08x (?)
Added
String.data.Empty 87 89 88
String.data.LargeUnicode 541 550 544
String.data.Medium 439 440 439
String.data.Small 377 380 378

Code size: -Osize

TEST OLD NEW DELTA RATIO
Regression
DataBenchmarks.o 39764 41740 +5.0% 0.95x

Performance: -Onone

TEST OLD NEW DELTA RATIO
Regression
DataCreateEmpty 1080 1170 +8.3% 0.92x (?)
ObjectiveCBridgeStubFromNSString 941 1017 +8.1% 0.93x (?)
Added
String.data.Empty 107 110 108
String.data.LargeUnicode 564 581 570
String.data.Medium 479 483 481
String.data.Small 426 430 428
Benchmark Check Report
⛔️⏱ String.data.Medium has setup overhead of 52 μs (12.7%).
Move initialization of benchmark data to the setUpFunction registered in BenchmarkInfo.
How to read the data The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

@palimondo
Copy link
Contributor

palimondo commented Feb 18, 2019

@ianpartridge Thank you for the work on these benchmarks!

I'll merge as soon as somebody fixes the failing tests on linux (unrelated to this PR). We can ignore the ⛔️⏱ String.data.Medium. I have verified locally that there is no setup overhead... the benchmark validation heuristic can sometimes misfire, when there is high variability between independent runs, as is the case here:

4e8fbf79-a49e-4910-8b89-e0c6b7ca2b41

@ianpartridge
Copy link
Contributor Author

Thanks @palimondo, I hope we can merge soon.

@palimondo
Copy link
Contributor

@swift-ci smoke test linux platform

@milseman
Copy link
Member

@swift-ci please smoke test linux platform

@palimondo
Copy link
Contributor

palimondo commented Feb 18, 2019

@milseman The Linux smoke test has been failing the whole weekend. This last one failed few minutes ago. Did somebody fix the CI yet? (it's not even accepting the requests via GitHub without excessive repetition...)

@palimondo
Copy link
Contributor

@swift-ci smoke test linux platform

@milseman
Copy link
Member

Yeah, @gottesmm says he's preparing a fix. Let's wait on that

@palimondo
Copy link
Contributor

Oh, I've notices somebody kicked the CI servers and @swift-ci started to respond again, so I've restarted the smoke test hoping that was all it needed… Sorry for wasting the ⚡️🥺

@milseman
Copy link
Member

#22692 I believe

@palimondo
Copy link
Contributor

palimondo commented Feb 18, 2019

@swift-ci smoke test linux platform

#22692 was merged by Mishal, even though the test failed on Linux in that PR… let's see if that's it!

@palimondo
Copy link
Contributor

Hmm… smoke test on Linux did successfully finish in #22673. Let's try again…

@swift-ci smoke test linux platform

@palimondo
Copy link
Contributor

@milseman Can you please ask around why is the Linux smoke test still failing? This is just an addition of a few benchmarks… the failure is clearly unrelated to this PR! I need to get some 💤😴...

@milseman
Copy link
Member

The failure is: TEST 'swift-package-tests :: build-swift-benchmarks-with-swiftpm.txt' FAILED, which could be related. The error message itself doesn't seem to be so we can try to clean or something. Other PRs are also failing, but for a different reason, so hold on a bit.

@milseman
Copy link
Member

@swift-ci please clean smoke test linux platform

@palimondo
Copy link
Contributor

palimondo commented Feb 19, 2019

OK, we are failing to build benchmarks on Linux with swiftpm: DataBenchmarks.swift:416:5: error: use of unresolved identifier 'autoreleasepool'

Cross platform Swift sucks!

@palimondo
Copy link
Contributor

palimondo commented Feb 19, 2019

@swift-ci please smoke test linux platform with #22707

Edit: Hmm… where are the docs for CI that tell me how to test 2 PR together?
I saw people use something like the above incantation, but it's not working for me ☹️🥺

Edit2: Aha, it had to be full URL in comment (GitHub shortens it for presentation)!
Continuous Integration: Cross Repository Testing

@palimondo
Copy link
Contributor

Please smoke test with following pull request:
#22707

@swift-ci please smoke test linux platform

@palimondo
Copy link
Contributor

For some reason the smoke test with combined PRs didn't work… The error on the console was the same. I guess we'll try again after the #22707 lands?

@palimondo
Copy link
Contributor

@swift-ci please smoke test Linux platform

@palimondo palimondo merged commit 1cbc0b3 into swiftlang:master Feb 20, 2019
@palimondo
Copy link
Contributor

Thank you @ianpartridge!

@ianpartridge ianpartridge deleted the benchmark-str2data branch February 20, 2019 14:52
ianpartridge added a commit to ianpartridge/swift that referenced this pull request Apr 24, 2019
Currently, `str.data(using:allowLossyConversion)` always bridges via
`NSString`.

As `String` is now natively UTF8 we can fastpath this conversion in the
case where the user requests UTF8 encoding.

A benchmark for this was previously added in swiftlang#22648.
itaiferber pushed a commit that referenced this pull request Apr 24, 2019
Currently, `str.data(using:allowLossyConversion)` always bridges via
`NSString`.

As `String` is now natively UTF8 we can fastpath this conversion in the
case where the user requests UTF8 encoding.

A benchmark for this was previously added in #22648.
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.

6 participants