I have an application with a large and growing number of routes. Perhaps route matching is so fast that the number of routes doesn't matter until it hits a thousand or more... but I'm wondering... If there is no use of flask.Module, how does the number of routes affect the time it take to resolve an endpoint? Does breaking an application up into Modules and registering them with url_prefix speed up resolution? What I'm wondering is whether url_prefix causes a two-step resolution process, where first a module is found base on url_prefix, and then the lookup within the module is performed. If endpoint resolution is a brute-force list iteration, then wouldhaving 10 modules of 10 routes each yield a worst-case of 20 match attempts ( 10 to find the module, 10 to find the route within the module), vs the same 100 routes without modules having worst-case of 100 match attempts? Also, if route matching involves a list iteration, then will there be efficiency gain in defining the most frequently accessed routes before defining the less frequently accessed ones -- e.g., if url "/foo/bar" is called 1000 times more often than any other url on the site, does it make sense to define the /foo/bar route before defining any of the others? Alternatively, since I'm using modules, I can pretty easily split this up into separate Flask apps.
Hi, On 2011-05-06 6:29 PM, Rob Mela wrote: > Perhaps route matching is so fast that the number of routes doesn't > matter until it hits a thousand or more... but I'm wondering... Route matching is indeed a O(n) worst case operation currently. I had some plans in the past to change the routing to internally reorganize the routes to collapse common prefixes but so far it does not appear to be useful to anyone. The matching on the request happens once, so it only causes a very minimal slowdown, even with many routes in place. If you notice a performance problem there, it can be fixed with a small number of changes to the Werkzeug routing system, no changes to the application would be necessary. Regards, Armin
Thanks, just looking for confirmation or debunk of the guess vis a vis O(n) worst case. As for performance, my instinct says that route matching for a couple hundred routes is a drop in the bucket compared to the Amazon SimpleDB calls I'm making on each request ( using boto ). My instincts are pretty good, but occasionally wrong, and never as good as numbers, so in some future phase, in the spirit of due diligence, I'll consider getting some numbers. Thanks. Den May 6, 2011 kl. 3:04 PM skrev Armin Ronacher: > Hi, > > On 2011-05-06 6:29 PM, Rob Mela wrote: >> Perhaps route matching is so fast that the number of routes doesn't >> matter until it hits a thousand or more... but I'm wondering... > Route matching is indeed a O(n) worst case operation currently. I had > some plans in the past to change the routing to internally reorganize > the routes to collapse common prefixes but so far it does not appear to > be useful to anyone. > > The matching on the request happens once, so it only causes a very > minimal slowdown, even with many routes in place. > > If you notice a performance problem there, it can be fixed with a small > number of changes to the Werkzeug routing system, no changes to the > application would be necessary. > > > Regards, > Armin
> if url "/foo/bar" is called 1000 times more often than any other url on the site, does it make sense to define the /foo/bar route before defining any of the others? IMHO, you might want to optimize codes dealing with /foo/bar as top priority. -- Think and code - imwilsonxu.net
Le 06/05/2011 18:29, Rob Mela a écrit : > I have an application with a large and growing number of routes. > > Perhaps route matching is so fast that the number of routes doesn't matter until it hits a thousand or more... but I'm wondering... > > If there is no use of flask.Module, how does the number of routes affect the time it take to resolve an endpoint? Hi, I wouldn’t worry about that until a *large* number of routes. To get an idea of what "large" means, remember that computer do *billions* of cycles per second these days. There is only one rule when it comes to performance: measure, measure, measure. You want to "profile" (google for "python profiling") your application to see where it spends its time. If and only if you see performance problems (eg. this particular request takes too long), look at the profile results and see what takes the most time and could be made faster. For web application however, common wisdom is that any request your app makes to a database (eg. with sqlalchemy) takes much longer than anything your framework does, such as routing URLs. Yet again, you can’t know until you’ve measured. Regards, -- Simon Sapin http://exyr.org/