On Fri, 2012-05-11 at 10:09 +0100, Michael Meeks wrote:
> we actually precisely know our offset from the beginning of the chain/array
> ( which is nNew/nPageSize ).
hmm, that escaped me entirely. Been trying to find a loophole that
invalidates that e.g. 10 20 30 40 where 20 is the first entry. Bu
On Thu, 2012-05-10 at 21:56 +0100, Caolán McNamara wrote:
> with a scenario of nBgn = 11, nRel = 2, desired result is 13
Ah ! how stupid of me, I missed that - but this case is almost totally
pointless ;-) we are just victims of this optimisation of starting in
the middle - which means we
On Thu, 2012-05-10 at 17:37 +0100, Michael Meeks wrote:
> Surely that should read:
>
> nBgn = m_aPageCache[nRel];
>
> or did I go a bit crazy ? [ I'm trying to turn the above into that
> mentally and giving up ;-].
how about a 4 element chain of 10 11 12 13
with a scen
Hi there,
On Thu, 2012-05-10 at 16:06 +0100, Caolán McNamara wrote:
> fdo#47644 big 18 meg .doc is super dooper slow to load, mostly because
> of the extra checks I added to sanity test .doc file during parsing.
:-)
> 1st attachment gets us back to where we came from in terms of
> perfor
fdo#47644 big 18 meg .doc is super dooper slow to load, mostly because
of the extra checks I added to sanity test .doc file during parsing.
Turns out that seeking backwards in the those ole2 formats is incredibly
slow, this might affect other formats like xls and ppt that use some of
the shared "ms
