<div dir="ltr"><div dir="ltr"><div>Hi,</div><div class="gmail_quote"><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"><br>
The database lives on disk in ${portdbpath}/registry/registry.db. It has<br>
to, or we wouldn't have the D in ACID [1].<br>
<br></blockquote><div><br></div><div>Probably then it should make a huge difference in hdd or fusion drives. All tests I made were on ssd.</div><div>Also I tried connecting an external hdd, but when I tried installing MacPorts base on it, while configuring</div><div>it gave me errors saying something like specify —build, —target and —host.</div><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">
An SQL database is likely not optimal for the access pattern of trace<br>
mode. Using another way of looking up file ownership would be a good<br>
direction to explore. Perhaps also look at doing more caching if<br>
possible, of negative results as well as positive.<br></blockquote><div><br></div><div>In general what I found is, like in port gettext, out of 400,000 calls to the sever, 50,000 calls need to get queried through registry.</div><div>Remaining 350,000 are always allowed or always denied prefixes such as /bin.</div><div>Till now I was simply caching any path returned from __darwintrace_sandbox_check(). Before I never noticed 350,000 times server is asked only for prefixes. This led to many cache miss in case of prefix searches.</div><div>When I do caching of all this data, making shared memory capable of handling prefixes also. only “300” calls actually go to server. This actually means most of the time socket doesn’t even need to get setup.</div><div>Doing this, gettext took (real:11m.9.701s, user:12m47.990s,sys:6m51.499s) which is pretty much an improvement compared to last time.</div><div><br></div><div>Although due to __darwintrace_setup(), being called every time before path lookup, setup gets done every time for no reason. Also path normalisation code is mixed up with path lookup . I guess I should try and modularise them somehow before next testing.</div><div> <br></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">
<br>
And most importantly, do some profiling so you know what is actually<br>
taking the time. Even if you just print out a bunch of timestamps at<br>
different places you at least know something.<br></blockquote><div><br></div><div>That really helped.</div><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">
<br>
- Josh<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/ACID_(computer_science)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/ACID_(computer_science)</a></blockquote><div><br></div><div>Thanks for the help,</div><div>Mihir </div></div></div></div>