Skip to content

[NO-TICKET] Trim unneeded headers from gem#5

Merged
ivoanjo merged 6 commits into
masterfrom
ivoanjo/clean-unused-files
Nov 6, 2024
Merged

[NO-TICKET] Trim unneeded headers from gem#5
ivoanjo merged 6 commits into
masterfrom
ivoanjo/clean-unused-files

Conversation

@ivoanjo

@ivoanjo ivoanjo commented Oct 28, 2024

Copy link
Copy Markdown
Member

What does this PR do?

This PR further reduces the size of the gem:

  • Size of lib/:
    • master: 8.3 MiB
    • ivoanjo/clean-unused-files: 4.3 MiB
  • Packaged .gem file size:
    • master: 1.2 MiB
    • ivoanjo/clean-unused-files: 669 KiB

It does this by removing files that are not actually needed by the dd-trace-rb gem to work. I've used the new find_includes.rb script + a bit of manual checking to find files that aren't actually needed.

I've also tweaked the .gemspec to exclude a few files that aren't actually needed from the packaged gem.

Motivation:

Reduce shipped + installed size of gem.

Additional Notes:

N/A

How to test the change?

I've manually tested the changes by pointing the dd-trace-rb gem to this gem, and making sure that both bundle exec rake clean compile and bundle exec rspec spec/datadog/profiling/ continue to work fine for all the expected Rubies.

(It's also possible to use CI to do this, although to speed up testing I only did it locally)

These files are not needed by the `datadog` gem and thus can be
removed on our fork.
These headers are not currently needed by the `datadog` gem, and thus
we can go ahead and remove them.

(We can always re-add them later)
We're not using it ATM :)
This is the script I've used to find which headers I could delete.
@ivoanjo
ivoanjo requested review from a team, TonyCTHsu and sarahchen6 October 28, 2024 11:20

@Strech Strech left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Holy-moly AI is taking our jobs! 🚀

@TonyCTHsu

TonyCTHsu commented Oct 28, 2024

Copy link
Copy Markdown
Contributor

Questions:

  • What would be the workflow look like when we rebase on the latest upstream (debase_ruby-core-source)?
  • What would be an effective way to verify the changes?

@ivoanjo

ivoanjo commented Oct 28, 2024

Copy link
Copy Markdown
Member Author

We discussed this during our 1:1, but I'll write it down for posterity:

What would be an effective way to verify the changes?

If the profiler compiles it should be correct. We can additionally run the profiler test suite to be extra sure, but given how C is a static compiled language, I'd expect any issue with reducing the headers to show up immediately when the profiler gets compiled.

What would be the workflow look like when we rebase on the latest upstream (debase_ruby-core-source)?

Ideally, we'd need to manually trim new sets of headers in the same way -- e.g, when the 3.4.0 stable headers come out, we'd do the same change; this is why I left the find_includes.rb tool in the repo.

But such a change is actually optional, so we can also chose to just sync with upstream and not do the clean up immediately after (at the cost of shipping a few more files that we need to).

@sarahchen6 sarahchen6 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Wow impressive!

@marcotc marcotc left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

🧹

@ivoanjo

ivoanjo commented Oct 29, 2024

Copy link
Copy Markdown
Member Author

I'll hold on merging this as @TonyCTHsu wanted to try to add some automation to validate these changes.

@lloeki lloeki left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Sorry to rain on the parade but I'm really not too keen on merging this.

EDIT: consider #6 instead

Comment thread find_includes.rb
Comment on lines +5 to +7
# `find_includes.rb vm_core.h iseq.h ractor_core.h` we get a rough list of headers that are not needed by the
# datadog gem. Always remember to validate the result -- this tool isn't perfect (for instance it doesn't detect that
# thread_pthread.h is in use).

@lloeki lloeki Oct 30, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

removing files that are not actually needed by the dd-trace-rb gem to work

This seems a bit backwards: datadog-ruby_core_source is a dependency of dd-trace-rb, but this introduces a circular dependency back from datadog-ruby_core_source to dd-trace-rb: which headers to pass to the tool is dd-trace-rb knowledge.

The mention that the tool isn't perfect† doesn't bode well either. It is also AIUI non-reversible, not telling you that suddenly you need a header that isn't there.

Combined with the huge resulting diff, I am not confident with a merge.

† Given that C99 preprocessing is sort of Turing complete the only way to surefire know is by running a full-blown C preprocessor, like cc -E...

@ivoanjo

ivoanjo commented Nov 4, 2024

Copy link
Copy Markdown
Member Author

Me and @lloeki discussed this PR vs #6 a bit.

For SSI, it makes sense to delete as much as possible, so we could even delete all of the header files, since we don't
support profiling in SSI. (And the path towards profiling + SSI is probably not going to go through these headers.)

I've extended the comment on find_includes.rb to hopefully make it more clear:

  1. What headers you should start from
  2. What the issue with thread_pthread.h is
  3. How to validate that a set of headers is correct
  4. How to apply this optimization to new sets of headers in the future

@lloeki lloeki left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks for adding the comments, it is much more actionable from an external perspective.

For SSI, it makes sense to delete as much as possible, so we could even delete all of the header files,

Indeed as of today without profiling we can go down to hack datadog's gemspec and remove the dependency, or keep the dependency and simply remove all headers post install.

So with such a change this changeset ultimately only benefits non-SSI installs.

since we don't support profiling in SSI. (And the path towards profiling + SSI is probably not going to go through these headers.)

That may change: I believe the requirement for no-compile+no-write when injection happens can - and arguably should - be addressed, even if it means building the C profiling extension per patch (or patch range) version.

While I find the proposal too complex, circular, and tricky to maintain I can't put forward a cogent argument to not merge, especially as this is a "two-way door".

So feel free to go ahead.

Comment thread find_includes.rb
Comment on lines +27 to +28
# `#include THREAD_IMPL_H`, with this `THREAD_IMPL_H` being provided by the auto-generated "ruby/config.h" file.
# Thus, this detection fails for this file.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

That's where we would need an actual C preprocessor ;)

Comment thread find_includes.rb
Comment on lines +20 to +22
# Currently this script should be used as `find_includes.rb vm_core.h iseq.h ractor_core.h`. These headers are the
# ones included in
# https://github.com/DataDog/dd-trace-rb/blob/master/ext/datadog_profiling_native_extension/private_vm_api_access.c .

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Wouldn't find_includes ext/datadog_profiling_native_extension/private_vm_api_access.c work?

Or shouldn't it be made to? (i.e finding the intersection between private_vm_api_access.c includes and the ones provided in this gem)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

It could indeed be made to work with it, although it'd need to be updated to ignore any headers in dd-trace-rb and handle the different folders correctly.

Comment thread find_includes.rb
# Thus, this detection fails for this file.
#
# 3. How to validate that there are no missing headers? To validate a set of headers is enough, build dd-trace-rb
# with those headers on linux/docker (`bundle exec rake clean compile`). If it passes, it's enough!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Sounds like a test in this repo would be useful:

  • [CI] clone this repo at the current git SHA
  • clone DataDog/dd-trace-rb's master in some tmp dir
  • cd into it, hack the Gemfile to point to this gem's cloned dir, and attempt compilation

Note: this is what I'm doing in libv8-node: cloning and building downstream mini_racer, and running a small set of mini_racer tests.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@TonyCTHsu mentioned wanted taking a stab at it; TBH it would be nice to have that automation, but I was hoping to not block on it (since as usual, I have many other profiler things to work on)

@ivoanjo

ivoanjo commented Nov 6, 2024

Copy link
Copy Markdown
Member Author

So with such a change this changeset ultimately only benefits non-SSI installs.

It will benefit SSI too until we do the above delete change; which we haven't done yet ;)

That may change: I believe the requirement for no-compile+no-write when injection happens can - and arguably should - be addressed, even if it means building the C profiling extension per patch (or patch range) version.

Supporting SSI customers would be great, and I hope to get to it in the short/medium-term.

@ivoanjo
ivoanjo merged commit f09d3aa into master Nov 6, 2024
@TonyCTHsu
TonyCTHsu deleted the ivoanjo/clean-unused-files branch November 7, 2024 09:54
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.

7 participants