power-media / prado3

Automatically exported from code.google.com/p/prado3
Other
0 stars 0 forks source link

Prado object-creation performance micro-optimizations #433

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
While profiling my Prado web application I've discovered that there are a lot 
places where Prado creates - and then in the caches serializes and stores - 
objects that aren't actually ever used during the page cycle. These are mostly 
subproperty-wrappers, but there are also other places where this happens.

I've identified a few of them and created a patch that makes sure that said 
objects are only created when that seems neccessary. This lowers the size of 
the cached templates/configuration files, and also the run time in cases where 
those objects aren't actually needed.

The patch set also contains an extended variant of TUrlMapping which supports 
specifying constant parameters. The latter are GET parameters that are 
automatically set to a value specified in the urlmap configuration when a 
matching url has been invoked. This can be used to map parts of the url to a 
predefined set of values (instead of directly using them), or translate some 
url parameters 1:1 to different values (see multilanguage support in urls).

Btw. url mapping might be worth a slight rewrite in the future, because it 
seems to be one of the biggest resource hogs in terms of object creation and 
serialization. A hundred url patterns create literally thousands of object at 
every single page request, even if serving the page requires only a creation of 
a handful objects (like in a typical TRpcServer call scenario). 

A hierarchically structured approach (ie. in which url maps are stored in a 
tree structure, based on url path parts, and each node/leaf is only loaded when 
needed, because its parent fragment matches the current url) instead of the 
current flat model might lower the number of objects used by url mapping 
considerably.

Original issue reported on code.google.com by google...@pcforum.hu on 20 Jan 2013 at 3:24

Attachments:

GoogleCodeExporter commented 8 years ago
Some comments on the patch:
 - it's probably based on a quite old version of prado; please consider rebasing your working copy on a more recent version; 
 - at TUrlMapping.php:702 the name of an array has changed ($matches2[$key]): it seems an error to me
- i didn't really find the patch that enables constant parameters in TUrlMapping

Original comment by ctrlal...@gmail.com on 21 Jan 2013 at 7:01

GoogleCodeExporter commented 8 years ago
Right. I've implemented that in a subclass, which also adds caching 
functionality to the url mapping, which otherwise is always reparsed from the 
.xml file (unless the PHP style configuration is used, in newer versions).

The new constant parameter feature can be used just like the original 
"parameters" parameters, except that the supplied value will be treated as a 
simple string constant instead of a regular expression. Eg:

<url ServiceParameter="MyPage" pattern="/mypage/mypath/list/detail/{pageidx}" 
parameters.pageidx="\d+" constants.listtype="detailed"/>
<url ServiceParameter="MyPage" pattern="/mypage/mypath/list/summary/{pageidx}" 
parameters.pageidx="\d+" constants.listtype="summarized"/>

after which when querying the request parameters, the application will see the 
"lisstype" parameter present (even through not supplied in the request) and 
equal to "detailed" or "summarized", depending on the friendly url used, which 
practically will function as a table-based validation and translation of 
specified, fixed-set parameter values.

Please consider the attached code donated.

Original comment by google...@pcforum.hu on 21 Jan 2013 at 10:15

Attachments:

GoogleCodeExporter commented 8 years ago
Thank you. I'm currently reviewing the code in order to add it to prado.

Original comment by ctrlal...@gmail.com on 27 Jan 2013 at 10:57

GoogleCodeExporter commented 8 years ago
Created ticket #437 for the merge of the donated code, thank you.

Original comment by ctrlal...@gmail.com on 5 Feb 2013 at 11:37