There is a PHP framework taking care about generating links within an application. Each (potential) page is an object and can tell whether it may be called depending on e.g. user, context, data or arbitrary other things. This ensures that only valid links are shown while anything else can be either suppressed, replaced by text or throw an error.
I have been using this for years and am quite pleased with it, but recently I’ve run into a memory problem with a table containing >100 (invalid) links. In pseudo-code the relevant section looks kind of this:
function getLink() : URL {
try {
$page = [...get it somewhere...]
$url = $page->howToCallMe();
// decorate the URL with text and style
}
catch (Exception $e) {
$url = NULL;
}
return $url;
}
class Page {
public function howToCallMe() : URL {
$page = clone $this;
// do a LOT of complex checks involving
// modifying page or creating of other objects
// within it - these changes are the reaseon
// for the clone statement.
// either returns an URL in $url or throws
// exceptions of various types depending on
// if this page may be called in the given
// context
return $url;
}
According to memory_get_sage()
I loose ~500k per calling getLink()
with an invalid page – which is far too much. If I replace howToCallMe()
with the assignment of a simple, static URL, all problems are gone, if I force the links to be valid (by granting the appropriate permissions to the user) and thus avoid an exception to be thrown, problems are gone.
So – what to have a closer look at? I know that no definite answer can be given due to the pseudo-code, but I am not (yet?) able to reduce the problem to a size I could post here. My hope is that there are some elementary pitfalls you should avoid (e.g. allocated objects are not released if an exception is thrown which seems not very likely to me) if you have to care about your memory footprint; these 500k must be used by something. I have looked around a bit but have not found useful hint so far.
(I actually did try adding unset($e)
in the catch
clause, but this did not change anything. Obviously the exception object is destroyed correctly at the end of getLink()
.