Try this and you see what I mean:
Code: Select all
EnableExplicit
Define n.l, nEnd.l = 5000
Define i.l, iEnd.l = 10000
Define tStart.l, tExec1.d, tExec2.d
NewList l1.l()
For i = 1 To iEnd
AddElement(l1())
l1() = i
Next i
tStart = ElapsedMilliseconds()
For n = 1 To nEnd
For i = 1 To 10
SelectElement(l1(), i)
Next i
Next n
tExec1 = (ElapsedMilliseconds() - tStart) / 1000.0
tStart = ElapsedMilliseconds()
For n = 1 To nEnd
For i = 9990 To 10000
SelectElement(l1(), i)
Next i
Next n
tExec2 = (ElapsedMilliseconds() - tStart) / 1000.0
MessageRequester("Timing", "List begin: " + StrD(tExec1, 3) + #LF$ + "List end: " + StrD(tExec2, 3))

I understand that going from one index in the list to another means,
the program has to scan over all items inbetween,
but going, for example, from index 9999 to 10000 should be the same
as using NextElement(), but instead the list is always scanded from the start!!
The linkedlist library already uses a flag to avoid the problem of
using ChangeCurrentElement() (at least it was so in previous versions),
which will make the list index invalide.
But using ListIndex() rescaned the list once and reseted the flag to show
that the index is valide again, so way not use this flag to have a save way
to go from one index of SelectIndex() to another in a faster way?
And before someone suggested to use NextElement() to go from index 9999 to 10000,
this was just an example for the (slow-)speed, it is also true for 7777 to 666

And I would rather not have to use a loop with NextElement() / PreviousElement() to iterate throgh the list,
which is much faster at the moment.
Greatings
technicorn