Walk through 228,177 compiled functions.

What you are looking at

• Names come from the source code. Each source file was compiled on its own with clang at -O0, -O1, -O2, -O3 and -Os, built as a macOS dylib and stripped with strip -x; the disassembly is from that stripped file. Project build scripts were not run. Calls to other functions in the same project appear as sub_XXXX, calls into libraries keep their names.
• The call tree is read from one build of each function, -O0 when there is one. A project's files are linked into one dylib per level, so a sub_XXXX call can go to any file of the project; it is shown with its real name when that function is also in the dataset. In the builds shown here that is true for 80% of internal calls. The rest were not kept in the dataset, and for those you see only their size and the library functions they call. ext_XXXX is a function from a project file that did not compile.
• Only functions defined inside a project are present. A libc name such as memcpy appears only where a project ships its own copy; calls into the system C library are leaves in the tree.
• Search matches name tokens: ComputeCRC32 is found by crc32 and by compute crc; the last word can be a prefix. There is no search over code.
• Each record shows the first 24 lines of the function. The full bodies are in the dataset on Hugging Face (config v4).
• For the 2,000 functions in the fixed test sample, the record also shows what the v6 model predicted from the stripped code. It gets the name fully right (token F1 = 1) for 31 of them, so read its descriptions as guesses.
• Every project keeps its own license, shown on each project and record. License texts: licenses/ and LISANSLAR.md.

Use the index directly

Everything on this page is read from static files on the search-index branch through jsDelivr. Opening a project reads one file of at most 90 KB; a search usually reads 70–160 KB.