Browse Prior Art Database

Scheme for exploiting static function definitions in a dynamic language. Disclosure Number: IPCOM000180301D
Original Publication Date: 2009-Mar-06
Included in the Prior Art Database: 2009-Mar-06
Document File: 2 page(s) / 57K

Publishing Venue



Related publication "Scheme for managing function entries in function table in dynamic languages" (Nicholson, Hayton, Fernandes, Slattery and Tatsubori, 2009) describes a scheme for reducing the processing needed to service PHP web requests by preserving the function table from request to request. The scheme in that article achieves efficiency by re-using the function table from request to request. This is implemented by removing all user functions from the function table at the end of a request so that the table can be re-used for a subsequent request and will continue to contain the entries for extension functions. This article builds on that by suggesting ways in which selected function table entries may be safely preserved from request to request.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Scheme for exploiting static function definitions in a dynamic language .

This article builds upon the related publication titled "Scheme for managing function entries in function table in dynamic languages" (Nicholson, Hayton, Fernandes, Slattery and Tatsubori, 2009) [1].

    The present article extends [1] by maintaining some entries in the function table relating to user functions from request to request. This achieves even greater efficiency savings than [1].

    As described in [1] each new PHP request must appear to build a new function table containing all extension functions and any functions which are defined by the currently executing script.

    The typical structure of a PHP program is that it is built up of multiple script files. One of these script files contains the entry point. For example we might have two script files A.php and B.php. A particular request may be addressed to A.php as follows: GET http://my.server.address/my/prefix/path/A.php

    Consider the contents of A.php and B.php which are located at the absolute path /php/ on the filesystem of the webserver.
include "/php/B.php";
function funcA ($myparm) {
echo "hello from funcA";
include "$mypath";
function funcB ($myparm) {
echo "hello from funcB";


    In this case we can see that when a request is made for http://my.server.address/my/prefix/path/A.php the functions funcA and funcB are defined before any code is run.

    A real PHP application may be made up of hundreds of files defining many hundreds of functions on each request.

    It can be seen from the information presented above that it is possible to use analysis to determine a list of functions that must be defined before any code is run for any particular requested PHP path. This is the list of functions which are defined unconditionally in the file addressed by the filepath together with any unconditionally defined functions in files unconditionally included.

    This understanding can then be exploited by creating a function table which contains all of the extension functions plus any functions which can be statically determined to be always defined. A separate function table will be required for each requested path. Thus a request for http://my.server.address/my/prefix/path/C.php would not use the same stored function table as a request for http://my.server.address/my/prefix/path/A.php.

Page 2 of 2

    This scheme can achieve more significant performance improvements than the scheme presented in [1] because it can avoid adding some more entries into the function table on each request.

    The implementation of the runtime runs for a period of time without using the optimisation described here. During this time it records the history of path accesses so that it can determine the most frequently accessed paths.

    Using this information the runtime keeps a set of function tables which have pre-...