"Updating database of binaries" step very slow under Yosemite?
jberry at macports.org
Wed Oct 22 13:24:33 PDT 2014
> On Oct 22, 2014, at 1:06 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Wednesday October 22 2014 15:51:38 Jeremy Lavergne wrote:
>> On Oct 22, 2014, at 3:47 PM, Arno Hautala wrote:
>>> I'm pretty sure that the scan only checks newly installed files.
>> Only "new" (yet-to-be-scanned) files get added, then only the applicable files are checked during rev-upgrade.
> What's the point in scanning newly installed files? I thought the whole idea was to scan already installed files for ABI issues due to the newly installed (dylib) files?
The phase that seems to take some time, “Updating database of binaries” is really just recording which of the newly installed files are binary; this is then used for later checking of whether those binaries have been broken.
The code basically gets from the database the list of files whose state is not yet known (binary null), determines which are binaries, and writes that information to the database.
Something in that process takes longer than one would expect; that’s what needs to be investigated.
- It’s pretty easy to null out the binary field in the database
- I would run the code three times with the binary fields all nulled: once as it normally is; once by stubbing out the binary check (but writing a static value to the database); and once by performing the binary check but not writing to the database.
- This would at least give some information about what aspect of the task is taking so much time, and might give some ideas on where we need to look next.
I haven’t had a chance to do this, but it would be interesting to do…
> Or are we talking about the (other?) scan that bugs you after you cleaned out all those useless doc or translation files, claiming that such or so file is missing? :)
> macports-users mailing list
> macports-users at lists.macosforge.org
More information about the macports-users