Profiling mode may create inaccurate running time information.

[StarGazerM]

Hi: I am profiling ddisasm for "large" size binary (> 50 MB) using ddisasm "--profile" flag. I noticed that ddisasm's profiler is based on souffle's interpreter mode, but interpreter mode of souffle can have completely different behavior from compiled souffle c++ file. For example when I profile lean4 theorem prover binary, profiling result tells computation of block_overlap takes almost all running time (> 40min), however if I take out this query and running in compilation mode of souffle, this query take only takes less than 5 seconds.

Maybe we need some other way to do profiling, otherwise current profile information will be misleading

Binary and profiling result in here: https://drive.google.com/file/d/1izSSquNhkmbvPDT0DjcTKXS-UR858DTe/view?usp=drive_link

The rule:

block_overlap(Block2,Type2,Size2,Block1,Type1,Size1) :- 
   block_overlap(Block1,Type1,Size1,Block2,Type2,Size2).

block_overlap(Block1,Type1,(EndAddr1-BegAddr1),Block2,Type2,(EndAddr2-BegAddr2)) :- 
   block_candidate_boundaries(Block1,Type1,BegAddr1,EndAddr1),
   block_candidate_boundaries(Block2,Type2,BegAddr2,EndAddr2),
   Block1 != Block2,
   BegAddr1 <= BegAddr2,
   BegAddr2 < EndAddr1.

block_overlap(Block1,Type1,(EndAddr1-BegAddr1),Block2,Type2,(EndAddr2-BegAddr2)) :- 
   block_candidate_boundaries(Block1,Type1,BegAddr1,EndAddr1),
   block_candidate_boundaries(Block2,Type2,BegAddr2,EndAddr2),
   Type1 != Type2,
   BegAddr1 <= BegAddr2,
   BegAddr2 < EndAddr1.

block_overlap(Block1,Type1,(EndAddr1-BegAddr1),Block2,Type2,(EndAddr2-BegAddr2)) :- 
   block_candidate_boundaries(Block1,Type1,BegAddr1,EndAddr1),
   block_candidate_boundaries(Block2,Type2,BegAddr2,EndAddr2),
   (EndAddr1-BegAddr1) != (EndAddr2-BegAddr2),
   BegAddr1 <= BegAddr2,
   BegAddr2 < EndAddr1.

[StarGazerM]

Ah saw there is another profile flag in cmake configuration, will try and report back

[StarGazerM]

okay the profiler mode in cmake works perfect for me!