CMD API (rz_core_cmd_str) vs Direct API calling #3082
Replies: 4 comments 6 replies
-
Have you tried to use something like https://github.com/brendangregg/FlameGraph to see the difference between calls? |
Beta Was this translation helpful? Give feedback.
-
I suppose the You can find To test it again, could you instead benchmark the RzAnalysisFunction *fcn = rz_analysis_get_fcn_in(core->analysis, 0xf6e07c15, RZ_ANALYSIS_FCN_TYPE_ROOT);
rz_core_seek_and_save(core, fcn->addr, true);
PJ *pj = pj_new();
rz_core_print_function_disasm_json(core, fcn, pj); I believe this should have a similar speed to the |
Beta Was this translation helpful? Give feedback.
-
hi Including example code. The call to rz_core_analysis_bytes is very slow. That is the reason why rz_core_print_function_disasm_json, is also slow. I'll continue investigating rz_core_analysis_bytes, to see what is slow inside. Is better way to iterate the instructions than calling rz_core_analysis_bytes to get the vector and the iterate it.? here is the function and block sizes when it got very slow. (during block: #block# instructions: 14296 block size (read ok): 28602) function: fcn.f6e07c15, blocks: 53, ninstr: 29128 |
Beta Was this translation helpful? Give feedback.
-
Update and concluding from my side. I ended up extracting (copy) from rizin: "rz_core_analysis_bytes". Because of that a couple non-API (IPI) function were extracted: This allow me: IMO, if rz_analysis_mask get fixed and/or selected to be call by config (in case does not have a bug.), i won't need the copy out of rz_core_analysis_bytes. Right now I have don't have time to see the issue with rz_analysis_mask. (I suspect there is either a bug or slow implementation) Thanks. |
Beta Was this translation helpful? Give feedback.
-
hi
When I have the following call sequence:
core = rz_core_new();
RzCoreFile *f = rz_core_file_open(core, path.c_str(), RZ_PERM_R, UT64_MAX);
rz_core_bin_load(core, path.c_str(), UT64_MAX)
rz_core_cmd_str(core, "aaa");
rz_core_cmd_str(core, "s 0xf6e07c15")
rz_core_cmd_str(core, "pdf")
The addr (0xf6e07c15) is a function having a "big" block. When using that sequence of commands the function get disassembled very fast.
However using the API as follows:
RzAnalysisFunction* fcn = rz_analysis_get_function_byname(core->analysis, "fcn.f6e07c15");
rz_core_seek_and_save(core, fcn->addr, true);
PJ *pj = pj_new();
rz_core_print_function_disasm_json(core, fcn, pj);
Results in a significant slower disassembling. Note I'm using "pdf" command.
Do I am missing something?
My original intention was iterate all instructions using the API, but found this case.
I though that was my iteration being slow, but I reproduced the issue calling "rz_core_print_function_disasm_json()" which is basically doing the same.
So, asking here before debugging "rizin" :-)
Also notice the "pdfj" is slower not because is building the JSON, is because the way it is iterating the blocks and the instructions.
The cmd "pdf" is very fast and is calling rz_core_print_disasm() which is a big function, to copy...
However (rz_core_print_function_disasm_json) has a more explicit instruction iteration but very slow:
rz_core_print_function_disasm_json (do the following and is slow):
My question will be what is the faster way to iterate the all blocks->instructions?
Note: I can share the sample privately and testing code if required.
Beta Was this translation helpful? Give feedback.
All reactions