Skip to content
This repository was archived by the owner on Nov 1, 2020. It is now read-only.

Conversation

@Suchiman
Copy link
Contributor

@Suchiman Suchiman commented Jul 27, 2019

As discussed @MichalStrehovsky
TODO:

  • configurability
  • compression
  • disabling reflection fallback

Uncompressed numbers for sizes:
For a debug Hello World application (which includes debug information for corelib).

Section bytes count
rvaTokenMap 127.788 10.648
sequencePoints 1.012.608 111.737
stringHeap 70.160 767

@Suchiman Suchiman force-pushed the EmbeddedStackTraceLineInfos branch from 79fb7cc to 0bcc735 Compare July 27, 2019 22:04
}

ObjectDataBuilder sequencePointsBuilder = new ObjectDataBuilder(factory, relocsOnly);
foreach (var mappingEntry in mappingEntries)
Copy link
Member

Choose a reason for hiding this comment

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

@jkotas do you have an opinion about potentially using the NativeLayout data structures for this? This appears different enough that I don't see a straightforward mapping, but NativeLayout does have the compressed integer capabilities that we're after.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have been looking around a bit and ofc 927 holds true, so i've found ObjectDataBuilder has this method which only appears to be used for EHInfo, System.Reflection.Metadata uses those for the PDB writing (only supporting signed values up to ~268 million) and BinaryWriter uses this simple one which would take up 5 bytes for negative numbers but one could shift the sign bit from msb to lsb to combat that.

Copy link
Member

Choose a reason for hiding this comment

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

@Suchiman Suchiman force-pushed the EmbeddedStackTraceLineInfos branch 2 times, most recently from c9132da to a81f5da Compare August 4, 2019 21:45
@Suchiman Suchiman force-pushed the EmbeddedStackTraceLineInfos branch from a81f5da to f503758 Compare August 23, 2019 20:45
@jkotas
Copy link
Member

jkotas commented Apr 19, 2020

Closing stale PRs

@jkotas jkotas closed this Apr 19, 2020
@MichalStrehovsky
Copy link
Member

Sorry I didn't get back to this @Suchiman - I do think this is a very useful addition, but I also want to make sure that we can get the size on disk impact of this right:

  • When this is turned on, the size of the generated data structures should be as small as possible
  • When this is turned off, the resulting size is no worse than it was before this was added (which would imply still supplementing the dedicated stack trace information with reflection information to avoid duplication)

I haven't had a chance to sit down and think how it would be best to achieve that.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants