<div dir="ltr">Hi, <br><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
This is certainly an improvement. How does it compare with running the<br>
same builds without trace mode? The ideal scenario would of course be to<br>
have trace mode incur only a barely noticeable performance penalty.<br></blockquote><div><br></div><div>Kindly check out this link. I made the comparisons again for those ports.(I was stupid enough to not note down the comparisons last time)</div><div>Also, I made some changes to the code since that mail, for which I also made a PR.</div><div><br></div><div><a href="https://docs.google.com/spreadsheets/d/19OpjSl9Ys47Gp0vkwJ7Yi2b6x3JiRlI_EQm4-FUqZYc/edit?usp=sharing" target="_blank">https://docs.google.com/spreadsheets/d/19OpjSl9Ys47Gp0vkwJ7Yi2b6x3JiRlI_EQm4-FUqZYc/edit?usp=sharing</a></div><div><br></div><div>I will keep adding any new data to these sheets whenever I make more tests. </div><div>Also in case of some ports like db48 and glib2(+deps), optimisations didn’t work well. I will test ports cmake, mariadb, and some more </div><div>which I tested last time as well and they showed nice improvements. I will keep updating data along with tests.</div><div><br></div><div>I could figure out 2 points where I can make the library better</div><div>1) Darwin trace not always checks the registry. Like sometimes the case is of an always allowed/denied prefix such as /usr/include(always allowed) or /usr/local(always denied). Despite of this fact, shared memory would store complete paths. This point can be made much better if shared memory stores just the prefix in such cases and on the last character of prefix it marks * or some character to indicate all paths with this prefix are allowed. Also this happens really frequently. So maybe after doing this, optimisations will improve. </div><div>2) As the data struct for shared memory is a extension of a trie, each node stores huge arrays for every possible characters. It is possible for a path to contain any character from unicode, so making an array of size 256 and traversing through path by utf-8 representation is possible. But its rare to see chars 127-255 in paths and this leads to a huge wastage. So shared mem just doesn’t store such paths. Similar is the case for chars 0-32 which are just like carriage return, esc, etc Probably they can also be filtered out somehow. Because there are lots of nodes getting inserted, reducing this array size ends up reducing insertion time to a large extent.</div><div><br></div><div>Also thanks for providing me with the help.</div><div><br></div><div>Regards,</div><div>Mihir</div></div></div></div>
</div></div>