Failed cleanup

James Berry jberry at macports.org
Sat Jan 10 13:36:57 PST 2015


> On Jan 10, 2015, at 9:58 AM, Joshua Root <jmr at macports.org> wrote:
> 
> On 2015-1-11 00:18 , Clemens Lang wrote:
>> 
>> 
>> ----- On 10 Jan, 2015, at 12:28, Mojca Miklavec mojca at macports.org wrote:
>> 
>>> I already mentioned a while ago some annoying behaviour of macports:
>>>   sudo port uninstall <some port>
>>> (maybe also sudo clean) sometimes takes forever. I can uninstall 10
>>> ports, but the time won't multiply by 10, it seems that there's only a
>>> single very time consuming step somewhere in the process, but it's not
>>> always exactly reproducible.
>> 
>> Might be the registry VACUUM at the end. Do you see the uninstall output in
>> normal speed and then it hangs before returning?
> 
> That is what generally takes a lot of time after uninstalls. Ideally we
> would only vacuum when the amount of wasted space reaches a certain
> significant level, but that would not make it any quicker when it does
> happen, probably the opposite in fact. Not sure if we could add a
> progress indicator either.

We could check the ratio of free pages to total pages and VACUUM only when we reach a certain threshold. This would be VACUUM to recover unused space, but not necessarily to eliminate fragmentation. In general, I’d think VACUUM always takes about the same amount of time, given the same size of data: the algorithm is that a new file is created, and tables are copied into it one by one, I believe.

See pragmas for freelist_count <https://sqlite.org/pragma.html#pragma_freelist_count> and page_count <https://sqlite.org/pragma.html#pragma_page_count>.

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150110/4537e934/attachment.html>


More information about the macports-dev mailing list