Route: cache vs lazy load about core

[acoulton]

Interesting proposal, could you explain why this (especially dropping caching) would be better?

[WinterSilence]

Both versions work at same speed:
current - spends time on deserialization, problems with serialization closures
my - spends time on generation of regexp (it need not for all routes, in most cases, for 2-5 objects), removes external dependence (Kohana_Core).

[acoulton]

Do you have profiling to support that?

It must depend on pattern of site usage and order of route definitions. If most requests are to the last defined route, then all routes will have to be compiled every request.

We use a reasonable number of routes in our project and there's a very noticeable boost from using Route::cache so would want to be sure of the impact before dropping it.

Accept the point re serialising closures. Dependency on Kohana_Core could be removed by injection if necessary.

Maybe the solution is to add lazy load but keep Route::cache so people can choose which works best for them?

[WinterSilence]

Do you have profiling to support that?

Ok, add tests tomorrow.

Maybe the solution is to add lazy load but keep Route::cache so people can choose which works best for them?

These versions are not compatible (

[WinterSilence]

We use a reasonable number of routes in our project and there's a very noticeable boost from using Route::cache so would want to be sure of the impact before dropping it.

For example, we have 9 routes (50-60% requests) and default route (40-50% requests), then regexp compile not for all routes in 50-60% cases. Current code deserialize routes in 100% requests.

[acoulton]

We use a reasonable number of routes in our project and there's a very noticeable boost from using Route::cache so would want to be sure of the impact before dropping it.

For example, we have 9 routes (50-60% requests) and default route (40-50% requests), then regexp compile not for all routes in 50-60% cases. Current code deserialize routes in 100% requests.

But do you have profiling showing overhead of deserialize compared to overhead of compiling? I've not noticed an issue with deserialize in production. They're relatively small objects.

Your example slightly simplifies when you say "regexp compile not for all routes in 50-60% of cases". There'll be a percentage that compile 8/9 routes, some do 7/9, some do 6/9 etc.

Say for ease you have 100 requests a minute and traffic like this:

Route	req/min	compiles/min
1	9	9
2	9	18
3	9	27
4	9	36
5	9	45
6	9	54
7	9	63
8	9	72
9	9	81
default	46	460
total	100	865

With Route::cache you'd have 100 deserialize operations. With lazy load you have 865 compile operations. Is deserializing really more than 8 times slower than compiling?

Obviously like I said it depends on your traffic pattern and route definitions. Still though I think this isn't a change we should make on a hunch, you need to provide data showing the relative performance.

Maybe the solution is to add lazy load but keep Route::cache so people can choose which works best for them?

These versions are not compatible

Why? Surely if Route::cache forces all routes to compile then they can be cached, or am I missing something?

IMO unless you have profiling data we should close this. If you want to add lazy load that supports caching, then that would give people a useful choice eg if they want to use closures in filters.

[WinterSilence]

Why? Surely if Route::cache forces all routes to compile then they can be cached, or am I missing something?

Some cached routes contain not compiled regexp - need cache only compiled routes or recache if routes added\compiled.

In order to avoid problems with serialization can add a parameter $cache to route - if we add closure to filters, then set $cache = false and before caching routes we check this parameter.