2008/12/9 duncan <[EMAIL PROTECTED]>: > But it is often the case that you can make a good guess at what is > going wrong when what should be a fast operation is very slow. If you > see that it is fast for a small n but very slow for a somewhat larger > n, and if it looks like the algorithm is not linear, it's often the > case that the algorithm is not linear.
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. Oisín --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mnemosyne-proj-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mnemosyne-proj-users?hl=en -~----------~----~----~----~------~----~------~--~---
