Bump to Java.Interop/master/c794fabb - #532
Closed
jonpryor wants to merge 1 commit into
Closed
Conversation
Fixes: dotnet/java-interop#129 Generates debug symbols in Release builds. Processes `//constructor/typeParameters` in API XML. Pulls in cecil/mono-2017-02/0d05ab1d, for consistency with `external/mono/external/cecil`.
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Mar 28, 2017
A "funny" [^0] thing happened when trying to [update xamarin-android to use a newer Java.Interop][0]: while all the tests passed, the macOS+xbuild PR builder -- which actually runs the unit tests -- was *really slow*: [2 hr 26 minutes to run][1], vs. a more [normal 53 minutes][2]. Ouch. @radekdoulik tried to verify that it wasn't c794fab; *that* build took [1 hr 42 min][3]. *Something* between cecil/d0cb2b7 and cecil/0d05ab1 caused this, but we don't know what, and even if we knew, that might not matter. That said, we have found two apparent factors in the slowdown: 1. Using `ReaderParameters.ReadingMode` to `ReadingMode.Immediate` (084e9f7), and 2. Setting `ReaderParameters.ReadSymbols` to `true`. There also appears to be something "wrong" with the `.pdb` files that Roslyn on macOS is generating, in that the `.pdb` file appears to be invalid; no real details at this time. To verify: $ csharp -r:bin/Debug/Xamarin.Android.Cecil.dll csharp> using Mono.Cecil; csharp> var rp = new ReaderParameters (ReadingMode.Immediate) { ReadSymbols = true }; csharp> var ad = AssemblyDefinition.ReadAssembly ("path/to/Mono.Android.dll", rp); This "hangs", taking roughly 2 minutes to complete. (Oof.) Change things to *remove* `ReadingMode.Immediate`, e.g. csharp> var rp = new ReaderParameters () { ReadSymbols = true }; and `AssemblyDefinition.ReadAssembly()` is instantaneous. So...why are we using `ReadingMode.Immediate`? Hysterical raisens, mostly: as commit 084e9f7 noted, in the "previous world order" Cecil loaded everything in memory, so it seemed perfectly reasonable that to fix various file sharing bugs we could/should continue doing the same thing. That turned out to be...not quite right; see 40b75e9, in which the `DirectoryAssemblyResolver` instance had to be turned into a member instead of a constructor local parameter, because code "down the call stack" was implicitly using the `DirectoryAssemblyResolver` instance. This means we don't *really* need `ReadingMode.Immediate` *at all*, and thus removing it should (1) not break anything, and (2) provide us with a very nice performance improvement. [0]: dotnet/android#532 [1]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/775/ [2]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/769/ [3]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/776/ [^0]: Everything is always "funny"...
radekdoulik
pushed a commit
to dotnet/java-interop
that referenced
this pull request
Mar 28, 2017
A "funny" [^0] thing happened when trying to [update xamarin-android to use a newer Java.Interop][0]: while all the tests passed, the macOS+xbuild PR builder -- which actually runs the unit tests -- was *really slow*: [2 hr 26 minutes to run][1], vs. a more [normal 53 minutes][2]. Ouch. @radekdoulik tried to verify that it wasn't c794fab; *that* build took [1 hr 42 min][3]. *Something* between cecil/d0cb2b7 and cecil/0d05ab1 caused this, but we don't know what, and even if we knew, that might not matter. That said, we have found two apparent factors in the slowdown: 1. Using `ReaderParameters.ReadingMode` to `ReadingMode.Immediate` (084e9f7), and 2. Setting `ReaderParameters.ReadSymbols` to `true`. There also appears to be something "wrong" with the `.pdb` files that Roslyn on macOS is generating, in that the `.pdb` file appears to be invalid; no real details at this time. To verify: $ csharp -r:bin/Debug/Xamarin.Android.Cecil.dll csharp> using Mono.Cecil; csharp> var rp = new ReaderParameters (ReadingMode.Immediate) { ReadSymbols = true }; csharp> var ad = AssemblyDefinition.ReadAssembly ("path/to/Mono.Android.dll", rp); This "hangs", taking roughly 2 minutes to complete. (Oof.) Change things to *remove* `ReadingMode.Immediate`, e.g. csharp> var rp = new ReaderParameters () { ReadSymbols = true }; and `AssemblyDefinition.ReadAssembly()` is instantaneous. So...why are we using `ReadingMode.Immediate`? Hysterical raisens, mostly: as commit 084e9f7 noted, in the "previous world order" Cecil loaded everything in memory, so it seemed perfectly reasonable that to fix various file sharing bugs we could/should continue doing the same thing. That turned out to be...not quite right; see 40b75e9, in which the `DirectoryAssemblyResolver` instance had to be turned into a member instead of a constructor local parameter, because code "down the call stack" was implicitly using the `DirectoryAssemblyResolver` instance. This means we don't *really* need `ReadingMode.Immediate` *at all*, and thus removing it should (1) not break anything, and (2) provide us with a very nice performance improvement. [0]: dotnet/android#532 [1]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/775/ [2]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/769/ [3]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/776/ [^0]: Everything is always "funny"...
Contributor
Author
|
Obsoleted by PR #534. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes: dotnet/java-interop#129
Generates debug symbols in Release builds.
Processes
//constructor/typeParametersin API XML.Pulls in cecil/mono-2017-02/0d05ab1d, for consistency with
external/mono/external/cecil.