<div dir="ltr">Hi<div><br></div><div>The ideas page this time around has many ideas related to trace mode. </div><div><br></div><div>&#39;Speed up trace mode&#39; suggests implementation of a cache data structure to improve performance of trace mode.</div><div><br></div><div>I have been trying to understand the code related to trace mode. The darwintrace shared library gets linked to the process and the sandbox is defined in porttrace.tcl. The tracelib.c and .h files in pextlib1.0 set up the unix sockets to communicate with the darwintrace.dylib and build the filemap for darwintrace. Any violations of the sandbox are reported by darwintrace. The tracemode also respects recursively collected port dependencies by not counting them as violations which is done in portutil.tcl where the trace procedure actually executes.</div><div><br></div><div>I also read the gsoc2007 wiki for the project in which trace mode was implemented. The code has grown a lot in complexity since then.</div><div><br></div><div>After reading all this I am still not able to understand the project. Is the cache data structure (trie) supposed to store the file paths of the sandbox? How does it improve the performance? What are the bottlenecks to the performance of trace mode?</div><div><br></div><div>Kindly explain this project idea in greater depth.</div><div><br></div><div>I thoroughly enjoyed working for MacPorts last GSoC. I hope I will get a chance to contribute to it again for this year&#39;s GSoC.</div><div><br></div><div>Sincerely</div><div>Shashwat Pandey</div></div>