You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/debugging.md
+24Lines changed: 24 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -440,3 +440,27 @@ In the `scripts` folder of starknet-replay, you can find useful scripts for debu
440
440
> ./scripts/string-to-felt.sh "u256_mul Overflow"
441
441
753235365f6d756c204f766572666c6f77
442
442
```
443
+
444
+
## Debugging Compilation
445
+
446
+
If we encounter contracts/programs that take too long to compile, the first step is to pinpoint what is causing the long compilation times.
447
+
448
+
If we find that a particular libfunc is taking too much time to compile/optimize, we should consider moving that libfunc to the runtime. First, we need to check if it would give any improvements at all. To do this, we can "fake" a runtime call to trick the compiler into thinking that a particular libfunc is implemented externally. If we just "delete" the libfunc implementation, we may allow the compiler to optimize a lot of instructions away. This would hide the actual problem.
449
+
450
+
For details on how to do this, see the debugging functions `build_mock_runtime_call` and `build_mock_libfunc`. The latter is fully generic, and can be used as a replacement for any libfunc implementation.
451
+
452
+
For example, to check if the `eval_circuit` libfunc is taking too much time to compile, just replace this:
Note that sometimes the problem is not a libfunc, but the actual types involved. In these cases mocking a libunc may not help, as doing so would have to operate with those complex types anyway (particularly, loading them from pointers).
0 commit comments