Holes in article sequence

["François Pinard" <pinard@iro.umontreal.ca>]

Hi, people.

I've often seen complaints about inefficiencies induced by big holes in
the sequence of read article numbers, but I do not know the deep reason
behind such inefficiencies.  Would someone accept to enlighten me?

Is it backend dependent, or not?  Do those inefficiencies exist for `nnml'
in particular?  Is this an I/O related problem?  Do the particular holes at
both end generate inefficiencies?  For example, if I am revisiting a group
I did not see for a long while, will there be an extra inefficiency for
the size of the hole, besides the fact I have many articles to catchup?
Would the problem be merely related to the fact that Gnus expands lists
in memory instead of keeping them in interval form?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard