Reduce memory footprint and GC pressure

[pawelchcki]

This PR tries to optimize memory used by enabled integrations.

Each traced operation creates a span to store the data about it. Each created span has associated cost, both related to creation time and memory footprint of Span object.

Inspecting code and looking at measurements produced by derailed gem helped identify spots of unnecessary temporary object creation.

This PR reduces the incidence of temporary object creation and by switching storing of timestamps to much smaller Floats (before they were full Time objects, with some temporary objects created in between.

It reduces the maximum memory used by test application by up to 50%.

Examples of changes:

• each configuration access triggered creation of temporary Proxy objects, now they are cached
• quite a few strings were allocated with every span creation, .freeze-ing those solved that problem (at least for rubies 2.2+)
• Utils.truncate was used to truncate Strings, however it did so by creating around 3 temporary strings each with a copy of truncated string. New #truncate! method uses the fact that all those Strings can be safely modified to truncate the object without any temporary object creation.
• Time.now.utc requires 2 Time objects to be created. Process.clock_gettime(Process::CLOCK_REALTIME) only creates one Float which has much negligible footprint compared to Time.

[delner]

Could you explain some of the issues you suspect are taking up the most memory and how you're solving them? It would be great to have some context to consider these changes in.

[cbliard]

Maybe that's not the point in this pull request, but shouldn't Process::CLOCK_MONOTONIC be preferred over Process::CLOCK_REALTIME?

Processes like ntp can change the time, and the value returned by Process.clock_gettime(Process::CLOCK_REALTIME) can be affected, distorting the computed elapsed time. This is solved by using Process.clock_gettime(Process::CLOCK_MONOTONIC) which measures the elapsed time from some unspecified starting point.

This article goes in depth about this topic.

[delner]

@cbliard That's a good suggestion. I think we might address any changes to handling time in a different pull request altogether, given the complexity it introduces, and the impact it could have. We do already have #424 open as an implementation of Process::CLOCK_MONOTONIC, but that requires some more work itself. Perhaps that's the best place to discuss this kind of change.

[delner]

This all looks pretty good to me! 👍