[Xamarin.Android.Build.Tasks] don't copy pdb/mdb to $(OutputPath) #2935
Conversation
This file contains 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
Looking at the build output of a simple app:
> ls .\samples\HelloWorld\bin\Debug\*.pdb
Length Name
------ ----
1024 HelloLibrary.pdb
1304 HelloWorld.pdb
13943324 Mono.Android.pdb
153048 Mono.Security.pdb
1545052 mscorlib.pdb
106160 System.ComponentModel.Composition.pdb
393532 System.Core.pdb
43076 System.Net.Http.pdb
795468 System.pdb
325732 System.Runtime.Serialization.pdb
77008 System.ServiceModel.Internals.pdb
917588 System.Xml.pdb
There are *not* accompanying `.dll` files for many of these symbols.
Some of these symbols are also quite big!
I don't think we need to be copying these files to `$(OutputPath)` at
all; it doesn't make sense if their accompanying assembly isn't there!
If we remove the `<CopyIfChanged/>` calls in our targets, MSBuild will
handle copying the appropriate symbol files that are needed.
After this change, the directory looks like:
> ls .\samples\HelloWorld\bin\Debug\*.pdb
Length Name
------ ----
1024 HelloLibrary.pdb
1304 HelloWorld.pdb
~~ Results ~~
I did a performance comparison using the Xamarin.Forms app in this
repo. It seems the extra `<CopyIfChanged/>` call was taking between
25-50ms, but the bigger savings here is to not copy a 13MB
Mono.Android.pdb file. There could be bigger savings for developers
that have slower hardware (or don't have SSDs).
Overall it seems this change saves up to 50ms for a small project on
initial build, or incremental builds where an assembly changed.
|
Does someone need to look at this from the VS for Mac side? Or is that you now @joj? |
|
macOS failures are network-related: |
|
I will go do a manual test of this one in both IDEs Windows & Mac. |
|
Debugging seems to be fine with this change (in both IDEs). The only thing I can think of that might possibly break -- if you had a NuGet package via I'm not sure that currently works anyway, as we saw in: #2460 (comment) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Looking at the build output of a simple app:
There are not accompanying
.dllfiles for many of these symbols.Some of these symbols are also quite big!
I don't think we need to be copying these files to
$(OutputPath)atall; it doesn't make sense if their accompanying assembly isn't there!
If we remove the
<CopyIfChanged/>calls in our targets, MSBuild willhandle copying the appropriate symbol files that are needed.
After this change, the directory looks like:
Results
I did a performance comparison using the Xamarin.Forms app in this
repo. It seems the extra
<CopyIfChanged/>call was taking between25-50ms, but the bigger savings here is to not copy a 13MB
Mono.Android.pdb file. There could be bigger savings for developers
that have slower hardware (or don't have SSDs).
Overall it seems this change saves up to 50ms for a small project on
initial build, or incremental builds where an assembly changed.