S_Bartfast Posted July 15, 2017 Posted July 15, 2017 (edited) To be clear, the reason Brickficiency was slow is not because of the page scraping. Admittedly the scraping was slow but the great majority of the time was in the actual searching algorithm itself, which is necessarily very computationally intensive. As it is I find it hard to imagine how an exhaustive search (such as what Brickficiency does) could be made much faster. Mdoupe has most certainly implemented several clever optimisations to reduce the search time as much as he could and, while there are no doubt still other optimisations available that are yet to be implemented, doing an exhaustive search of the entire space (which is what is required to be guaranteed to find the best solution) is unavoidably expensive. There are however several non-exhaustive search methods available that focus on just key parts of the space. On the whole these non-exhaustive searches do a remarkably good job in just a fraction of the time, they are however not guaranteed to find the best solutions - though they can get surprisingly close. It is no doubt one of these non-exhaustive algorithms that BrickLink must be using to get the results they do. Edited July 16, 2017 by S_Bartfast Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.