search

sudara / melatonin_perfetto

Use google's perfetto performance tracing in JUCE plugins and apps
45 stars 8 forks source link

Compiling with melatonin_perfetto resulting in huge image size, fatal error LNK1248. #31

Open theeasyway opened 1 month ago

theeasyway commented 1 month ago

Building my VST project with melatonin_perfetto enabled results in a fatal linker error due to image size exceeding the 32-bit limit.

Back when I started using melatonin_perfetto, everything was fine. However, about a month or two ago, this linker problem started happening in the release build, and now it occurs in both debug and release.

Compiling with melatonin_perfetto enabled is adding almost 2GB to the image size.

Whether this issue is arising from melatonin perfetto itself or is something on my end? Monkeying with parameters in cmakelists.txt to try to save some space doesn't seem to have any effect. shrug DeNiro frownface

Error

fatal error LNK1248: image size (101C52C2C) exceeds maximum allowable size (FFFFFFFF)

Size Comparison

With melatonin_perfetto:

Without melatonin_perfetto:

Build Configuration

sudara commented 1 month ago

Wow. Thanks for the details. I haven't heard of this before.

The only thing suspicious to me is that without mela perfetto your SharedCode.lib is already 2GB!

I would focus on what's in there, or how it's getting that big in the first place. It seems like linking perfetto is doubling it? On a big app of mine SharedCode.a from Debug is 212M (macOS).

theeasyway commented 1 month ago

It seems I have been quite careless with my includes...

So I tidied up a bunch of includes and got my lib file size down to 1.7GB. I think there's more pruning to be done but that's as far as I've got for now. Whether that will fully explain the size I don't know.

Adding perfetto in now brings it up to 3.9GB and perfetto works again!

So a limited success so far and perfetto still seems to be on the hook, I'll have to do some more pruning in order to create some headroom or perfetto will become unusable again as the code continues to grow.

sudara commented 1 month ago

Unless there are Reasons why the project is that big, something seems pretty wrong, for example ODR violations where the compiled code somehow has a multitude of copies of the actual code.

  1. Are there valid reasons why you'd expect you code to be in the GB?

  2. Is your project from a Pamplejuce template?

  3. If so, around what date did you start the project (this will help me look at the config from that time).

  4. Let me know if the libraries are linked to with PRIVATE or INTERFACE or PUBLIC in the target_link_libraries(SharedCode call?

It looks like perfetto adds 12M for me on macOS.

On a new Pamplejuce project before adding perfetto:

-rw-r--r--  1 sudara  staff   148M Oct 29 00:54 libPamplejuce Demo_SharedCode.a

After:

-rw-r--r--  1 sudara  staff   160M Oct 29 00:56 libPamplejuce Demo_SharedCode.a

Let me know the answers to the above questions and I will check windows next. This definitely smells like a linking problem... And 148M on my Pamplejuce build also seems big, I should sanity check everything there too lol...

theeasyway commented 1 month ago
  1. No, but then I don't know anything about c++ linkers, except that I need them!
  2. No, though I'm starting to think it should be, given that testing and CI are now highly relevant for this project.
  3. n/a
  4. they were PUBLIC, changed to PRIVATE with no effect.

I think that a library I'm using (fluidlite) may be part of the problem: compiling with "/showIncludes" option shows so many includes that attempting to paste the debug output into a text editor causes my 32GB machine to run out of memory(!) and a chunk of them are related to fluid. I'm going to keep looking and also lookinto juce modules, c++20 modules and so on, to see if I can just avoid this mess entirely.