[pacman-dev] [PATCH] Convert package filelists to an array instead of linked list

Dan McGee dpmcgee at gmail.com
Tue Jul 19 11:28:55 EDT 2011


On Tue, Jul 19, 2011 at 6:57 AM, Allan McRae <allan at archlinux.org> wrote:
> On 19/07/11 20:01, Dan McGee wrote:
>>
>> This accomplishes quite a few things with one rather invasive change.
>>
>> 1. Iteration is much more performant, due to a reduction in pointer
>>    chasing and linear item access.
>> 2. Data structures are smaller- we no longer have the overhead of the
>>    linked list as the file struts are now laid out consecutively in
>>    memory.
>> 3. Memory allocation has been massively reworked. Before, we would
>>    allocate three different pieces of memory per file item- the list
>>    struct, the file struct, and the copied filename. What this resulted
>>    in was massive fragmentation of memory when loading filelists since
>>    the memory allocator had to leave holes all over the place. The new
>>    situation here now removes the need for any list item allocation;
>>    allocates the file structs in contiguous memory (and reallocs as
>>    necessary), leaving only the strings as individually allocated. Tests
>>    using valgrind (massif) show some pretty significant memory
>>    reductions on the worst case `pacman -Ql>  /dev/null` (366387 files
>>    on my machine):
>>
>>    Before:
>>      Peak heap:   54,416,024 B
>>         Useful heap: 36,840,692 B
>>         Extra heap:  17,575,332 B
>>
>>    After:
>>      Peak heap:   38,004,352 B
>>         Useful heap: 28,101,347 B
>>         Extra heap:   9,903,005 B
>>
>> Several small helper methods have been introduced, including a list to
>> array conversion helper as well as a filelist merge sort that works
>> directly on arrays.
>>
>
>
> Minor comments:
>
> Maybe want to look at consistency between the two places where file lists
> are read (local_db_read, _alpm_pkg_load_internal).  e.g. starting with size
> 4 vs 8, freeing excess memory at the end.
It actually starts with 8 in both cases, it just does it in different
ways. Look closer at it, but I agree it isn't all that clear, more
cleaver than necessary.

> Do you intend to just make filelist_operation return an array at a later
> stage?
I contemplated doing that, as it is the only user of the list_to_array
method right now. The tricky part there is the unknown size in advance
bit- we could have a list ranging anywhere in size from 0 to
max(len(lista), len(listb)).

-Dan


More information about the pacman-dev mailing list