Have you tried just waiting longer for it to complete the import?
10000 cards is quite a lot.
> I'll patch this. I wouldn't have cracked on it as hard as I did if I
> weren't planning on it, actually. I tend to think you should only be
> really critical of (free) software you are willing to help improve. I
> do have a question though. It does sound like the increase in time
> with number of items is greater than linear, and if that's the case
> there is probably only one spot that needs to be fixed. If this is
> inherent in the xml parser you're using I would consider it a bug in
> that library, and I would not bother to look for a cause in your code-
> I'd just switch in a better library. Do you know that your bottleneck
> is in the xml parser?
Not really, know, although I do know that the current parser we use is the
slowest of the lot.
I think this assumption should be tested rather than... well, assumed
:) O(n^2) isn't all that bad really; in this case, it could very well
just be that the xml parsing bottleneck is a relatively large constant
(usually ignored in big-O notation but it could be the limiting factor
You could write a script that generates random decks of 100, 500,
1000, 5000, 25000 cards etc., and time an import for each, to get a
quick estimate of the rate at which the runtime increases, rather than
spending possibly unnecessary time looking at the algorithm first. I
would if I knew any python. :)
This is why I suggested testing for different values of n; by
examining the rate at which the runtime increases you can quickly get
an idea of whether it is linear or not. Informed by this heuristic,
you could decide whether to first examine the constant factor (XML
processing library bottleneck) if linear growth is observed or the
rest of the algorithm (scheduler?).
> Anyway, if you're not joking, there is no reason to test the algorithm
> with successively greater numbers of cards when you know that it
> shouldn't take more than a second to import a million cards. If it
> takes minutes to do what should happen in less than a second you
> should just go figure out why that is the case.
I wasn't joking, and hopefully the above explanation clarifies what I
meant. If it takes minutes to do what should happen in less than a
second, yes you should go figure out why... but not spend 3 hours
looking at the scheduler if it turns out that it's caused by the XML
parsing library, nor spend 3 hours replacing the XML library with a
faster one if it turns out to be a polynomial or worse runtime in the
scheduler. If a (relatively) quick test might save you going down the
wrong path looking for optimisations, then it's worth doing.
Well, maybe option "Check for duplicates when adding new cards" is
answer. However it doesn't explain why deleting cards takes so much
That is because the listview widget is so slow. Switching to model-view should
be the answer there.