Reduce bloat

[DanRStevens]

General case for investigating and reducing bloat.

---

Compiling using Clang with -ftime-trace produces .json files next to the object files (.o), which can be loaded in Chrome to investigate compile times.
chrome://tracing/

---

Using nm with --print-size we can examine object files (.o) to determine what symbols contribute the most space to the object file. This can be used to determine which source code elements produce the largest amount of code bloat. It may also be helpful to pass the --demangle flag.

nm --print-size --size-sort --demangle .build/Debug_Linux_nas2d/intermediate/Configuration.o

Potentially the whole build folder can be scanned and sorted by symbol size:

find .build/Debug_Linux_nas2d/intermediate/ -name '*.o' -exec nm --print-size --size-sort --demangle {} \; | cut -d' ' -f2- | sort | uniq

It may be helpful to leave off the uniq call, to get a better sense of how often a symbol may appear.

---

Edit:
It's possible to run nm on the library file. By default, it contains sections for each internal object file. If the --size-sort flag is passed, it only sorts within an object file section. To sort the entire file contents, it may be necessary to pipe it through sort, and sort on the size field which is the second field (--key=2).

nm --print-size --size-sort --demangle lib/libnas2d.a | sort --key=2

---

We can get much of the same information as nm from the linker (ld) by generating a map file. This can be done with the custom makefile variable LDFLAGS_EXTRA:

export LDFLAGS_EXTRA="-Wl,-Map=mapfile"

The -Wl, is used to pass a flag to the linker. The -Map=mapfile is the linker flag to generate the mapfile. Use % as the filename to get the output filename with .map added.

---

Related:

• Issue Fix explicit template instantiation #1222
• Issue Add more support for direct use of Delegate #1218
• Issue Distinguish real paths from virtual paths in Filesystem #1215

[cugone]

This seemed super relevant to what you're doing. Some good advice therein: Why is My C++ Build So Slow?

[DanRStevens]

I was taking a look at the .json files generated by Clang with the -ftime-trace flag.

make CXX=clang++ CXXFLAGS_EXTRA="-ftime-trace"

The Chrome flame graph viewer (chrome://tracing/) does a pretty good job of presenting the output for a single source file.

Looking at single files doesn't necessarily give an immediate picture of how the build as a whole spends time. That got me thinking, maybe the .json files can be amalgamated and processed, with a tool such as jq, to give data for the entire build process.

Documentation for jq:
https://jqlang.org/manual/

---

First up, getting a list of all the .json output files:

find .build/Debug_Linux_nas2d/intermediate/ -name '*.json'

...
.build/Debug_Linux_nas2d/intermediate/Filesystem.json

---

Taking a look at one of the files shows it's very much intended for machine processing as there's no spacing or formatting:

cat .build/Debug_Linux_nas2d/intermediate/Filesystem.json

To pretty print the file, pass it through jq:

jq '.' .build/Debug_Linux_nas2d/intermediate/Filesystem.json

{
  "traceEvents": [
    {
      "pid": 43948,
      "tid": 43948,
      "ph": "X",
      "ts": 4447,
      "dur": 540,
      "name": "Source",
      "args": {
        "detail": "/usr/include/x86_64-linux-gnu/sys/cdefs.h"
      }
    },

...

---

As the output is long, it's not immediately obvious how many top level objects there are. This can be determined using keys:

jq 'keys' .build/Debug_Linux_nas2d/intermediate/Filesystem.json

[
  "beginningOfTime",
  "traceEvents"
]

The beginningOfTime field is a numeric value, which isn't of much interest, so we can ignore that and focus on traceEvents.

jq '.beginningOfTime' .build/Debug_Linux_nas2d/intermediate/Filesystem.json

1750236840485194

---

As the traceEvents field is an array, we can use an array iterator to focus on the data elements it contains:

jq '.traceEvents[]' .build/Debug_Linux_nas2d/intermediate/Filesystem.json

{
  "pid": 43948,
  "tid": 43948,
  "ph": "X",
  "ts": 4447,
  "dur": 540,
  "name": "Source",
  "args": {
    "detail": "/usr/include/x86_64-linux-gnu/sys/cdefs.h"
  }
}

...

{
  "pid": 43948,
  "tid": 43948,
  "ph": "X",
  "ts": 7397,
  "dur": 514,
  "name": "ParseFunctionDefinition",
  "args": {
    "detail": "operator|="
  }
}

...

---

There are a lot of entries for the various parts of the compilation process. For now I'm focusing on the green blocks in the flame chart, which seem to correspond with a name field equal to "Source". We can filter specifically for those entries using select:

jq '.traceEvents[] | select(.name == "Source")' .build/Debug_Linux_nas2d/intermediate/Filesystem.json

---

Looking at the objects representing source file processing, most of the fields aren't of much interest. We don't really care about the particular compiler Process ID during the compilation step. Really all we care about is the compile time, and which file. We can focus on that by using object construction to translate the objects into new objects with filtered fields. We want the dur field, which is the time needed to process the file in nanoseconds, and the args.detail field, which is the file path. We can rename these fields as we construct a new object:

jq '.traceEvents[] | select(.name == "Source") | {nanoseconds: .dur, file: .args.detail}' .build/Debug_Linux_nas2d/intermediate/Filesystem.json

...

{
  "nanoseconds": 63965,
  "file": "/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/memory"
}

---

This might be a good place to break, and do an aside on path normalization.

[DanRStevens]

Path Normalization with jq

There doesn't seem to be a built in realpath equivalent in jq. The closest seems to be sub and gsub for regular expression matching and replacement.

Note that regular expressions don't provide the full power of a parser, so there may be some simplifications here. The data we're working with is normal enough that we don't expect pathological cases, so simplifying assumptions may be valid.

Proof of concept, match anything that isn't a / up to a /../, and replace it with nothing:

echo '"a/../b"' | jq 'sub("[^/]+/../"; "")'

"b"

echo '"a/../b/../c"' | jq 'gsub("[^/]+/../"; "")'

"c"

---

We need to be careful about using . as it matches any character in a regular expression.

echo '"a/bb/c"' | jq 'sub("[^/]+/../"; "")'

"c" (Wrong)

To match a literal ".", and only that one character, we need to backslash escape it. Additionally, since the regular expression is in a string, which has it's own backslash escape codes, we need to double backslash escape it.

echo '"a/bb/c"' | jq 'sub("[^/]+/\\.\\./"; "")'

"a/bb/c"

echo '"a/../c"' | jq 'sub("[^/]+/\\.\\./"; "")'

"c"

---

Of course we need to be careful about accidentally matching two parent paths together (../../), especially at the beginning of a path:

echo '"../../a"' | jq 'gsub("[^/]+/\\.\\./"; "")'

"a" (Wrong)

We can guard against that by being more selective with the regular expression. Here we can use a negative lookahead (?!patternToNotMatch), where .. is the pattern to not match. Of course we need to double backslash escape the dots. This gives a negative lookahead pattern of (?!\\.\\.):

echo '"../../a"' | jq 'gsub("[^/]+(?!\\.\\.)/\\.\\./"; "")'

"../../a"

---

We also need to process an arbitrary number of ../. Example data so far contains at least 4 in a row, so we need to handle up to at least that many. One limitation of gsub, is it will only replace non-overlapping matches. However each ../ is paired with the element before it, and once removed, the next ../ is paired with the element before it from what's left. Those two matches overlap. Hence we need something beyond gsub. Early attempts also had accidentally paired folders, particularly before the negative lookahead part was added, so the code was iterating sub rather than gsub to ensure all replacements were iterated from the left side.

We can iterate an expression using repeat, while and until. The repeat function requires an error for termination, so maybe not useful here. The while and until operations use a boolean conditional, so would be useful here. Curiously the while and until operations are not simply the same thing with opposite conditions. The while operation works a bit unexpectedly, in that it generates values until the condition becomes false, and doesn't return the last value that makes the condition false (even though it needed to be calculated to check the condition). For that reason, we'll want to use until, which keeps iterating until a condition is true, and returns the single value that made the condition true.

For the boolean condition, we use test, so we can use the exact regular expression checked by the sub function. We can then invert that using the not boolean operator.

echo '"a/b/c/d/../../../../e"' | jq 'until(test("[^/]+(?!\\.\\.)/\\.\\./") | not; sub("[^/]+(?!\\.\\.)/\\.\\./"; ""))'

"e"

echo '"/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/memory"' | jq 'until(test("[^/]+(?!\\.\\.)/\\.\\./") | not; sub("[^/]+(?!\\.\\.)/\\.\\./"; ""))'

"/usr/include/c++/13/memory"

---

This seems to solve the path normalization part, and can be integrated with the previous part.