Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 0 additions & 58 deletions BenchMarkReport_0.md

This file was deleted.

154 changes: 154 additions & 0 deletions BenchMarkReports/BenchMarkReport_arm.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,154 @@
RTL Benchmarking Analysis Report

Date: 2025-09-08
Platform: Android tablet running Ubuntu via Turmax VM
CPU: 8 cores @ 1804.8 MHz
VM Environment: Ubuntu inside Turmax app
Load Average During Benchmarks: 3.9–6.9
Note: CPU scaling enabled; real-time measurements may include slight noise.


---

1. Benchmark Setup

All benchmarks measure call dispatch time for various call types under different workloads:

Direct Call: Native C++ function calls.

std::function Call: Calls wrapped in std::function.

std::function Method Call: Member functions wrapped in std::function.

Reflected Call: RTL reflection free function dispatch.

Reflected Method Call: RTL reflection method dispatch.


Two variants measured:

No-Return: Functions with void return type.

With-Return: Functions returning a value.


Iterations per benchmark varied depending on workload and time resolution, from millions of iterations at ~100 ns calls to hundreds of thousands at ~1 µs calls.


---

2. OS & Platform Context

Android environment running Ubuntu via Turmax VM introduces:

CPU scheduling variability

CPU frequency scaling

Minor memory virtualization overhead


Despite this, benchmark results are stable and reproducible, with only small variations across runs (~2–5%).

Load averages during tests were moderate-to-high (3.9–6.9), confirming RTL performance is robust under system stress.



---

3. Benchmark Results Summary

3.1 No-Return Calls

Call Type Time Range (ns) Overhead vs Direct

Direct Call 106–1176 0%
std::function 108–1448 5–23%
std::function Method 113–1247 7–10%
Reflected Call 110–1234 8–10%
Reflected Method 120–1260 10–14%


Observations:

Reflection overhead is modest and predictable.

Reflected free calls scale well, occasionally slightly cheaper than direct calls due to CPU cache effects.

Method calls are ~10–14% slower than direct calls at peak workload.


3.2 With-Return Calls

Call Type Time Range (ns) Overhead vs Direct

Direct Call 133–1292 0%
std::function 135–1296 0–5%
std::function Method 143–1300 0–4%
Reflected Call 177–1345 3–6%
Reflected Method 192–1376 5–10%


Observations:

Return value dispatch adds ~50–80 ns per call consistently.

Reflected methods with return are the heaviest, but overhead remains bounded below 10%.

Scaling is linear even at extreme workloads (hundreds of thousands of calls in µs range).



---

4. Scaling Insights

1. Direct and std::function calls scale linearly with workload; predictable performance.


2. Reflected calls scale well — overhead remains bounded, even at ultra-heavy call frequencies (~1+ µs/call).


3. Methods cost slightly more than free functions (~10%), consistent across workload.


4. Return-value functions consistently add ~50–80 ns, regardless of workload.


5. Minor run-to-run variation is attributable to VM CPU scheduling and frequency scaling, not RTL inefficiency.




---

5. Implications for RTL Usage

Dynamic Workloads: Reflection can safely handle millions of calls without becoming a bottleneck.

Game Engines / Scripting / Tooling: RTL is suitable for runtime event dispatch, editor tooling, and serialization/deserialization tasks.

Micro-optimization: For extremely hot loops (<10 ns per call), direct calls or std::function may still be preferred.

Overall: RTL provides a balanced tradeoff between dynamic flexibility and runtime performance.



---

6. Conclusion

RTL reflection overhead is modest and predictable:

~5–10% for free function reflection

~10–14% for method reflection

Return-value adds ~50–80 ns consistently


Even in heavy workloads (~1 µs per call), reflection remains viable for high-frequency dynamic systems.

This confirms RTL’s practicality in real-world applications, including heavy scripting, runtime tools, and editor-driven dynamic systems.


Loading
Loading