I have noticed that the number of dereferences to obtain the data needed for trace output from each zend_execute_data is almost the same in each time, and their contents are independent.
After traversing the chain of zend_execute_data, all zend_function_entry and oplines are retrievable with a single call to process_vm_readv(). And from there, all zend_strings for all function names and file names and all pointers to zend_class_entry are also retrievable in a single call to process_vm_readv(). Then all zend_string for all class names in a single call to process_vm_readv().
This should significantly reduce the number of system calls in situations such as Laravel applications where the depth of the calls exceeds 60.
The total amount of memory copy will not change, but it is worth a try.
Perhaps the same optimization can be done for adsr/phpspy#17.
I have noticed that the number of dereferences to obtain the data needed for trace output from each zend_execute_data is almost the same in each time, and their contents are independent.
After traversing the chain of zend_execute_data, all zend_function_entry and oplines are retrievable with a single call to process_vm_readv(). And from there, all zend_strings for all function names and file names and all pointers to zend_class_entry are also retrievable in a single call to process_vm_readv(). Then all zend_string for all class names in a single call to process_vm_readv().
This should significantly reduce the number of system calls in situations such as Laravel applications where the depth of the calls exceeds 60.
The total amount of memory copy will not change, but it is worth a try.
Perhaps the same optimization can be done for adsr/phpspy#17.