- 06 May, 2010 7 commits
-
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
- 05 May, 2010 33 commits
-
-
Huw Davies authored
-
Huw Davies authored
-
Sven Baars authored
-
Sven Baars authored
-
Sven Baars authored
-
Hans Leidekker authored
-
Hans Leidekker authored
-
Jacek Caban authored
-
Piotr Caban authored
-
Piotr Caban authored
-
Piotr Caban authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
Gerald Pfeifer authored
-
André Hentschel authored
-
Jörg Höhle authored
-
Jörg Höhle authored
-
Charles Davis authored
-
Damjan Jovanovic authored
-
Vincent Povirk authored
A big block chain is a linked list, and we pretty much need random access to them. This should theoretically make accessing a random point in the chain O(log2 n) instead of O(n) (with disk access scaling based on the size of the read/write, not its location). It theoretically takes O(n) memory based on the size, but it can do better if the chain isn't very fragmented (which I believe will generally be the case for long chains). It also involves fetching all the big block locations when we open the chain, but we already do that anyway (and it should be faster to read it all in one go than piecemeal).
-
Vincent Povirk authored
-
Damjan Jovanovic authored
-
Damjan Jovanovic authored
-
Henri Verbeet authored
-