OOP a paměťové nároky

Ahoj,
v návaznosti na http://diskuse.jakpsatweb.cz/?action=vthread&forum=9&topic=105103&page=-1 (@Jan Tvrdík: díky moc za reakci)

Shodou okolností jsem se na jiném foru setkal ještě s narážkou na paměťové nároky, což jsem záhy zkusil taky
a překvapilo mě číslo cca 950kB...a to mám menší aplikaci...počítal sem že kromě náročných aplikací jako Magento půjde spíš
maximálně o desítky kB.... nemůže jít o nějakou krpu v kódu?

Všiml jsem si že paměť se alokuje pro každou třídu jen jednou a nepůjde vyloženě o reference (dle článků od D. Grudla na phpfashion),
ref_count zůstává stejný ať měním atributy nebo ne, vypadá že asi skoro všechen prostor zabírají metody.
Taky odstraňování atributů mělo minimální vliv.
První třída teda zabere X kB.... každá další pak zabrala zhruba 1% z X.

Zkusil sem teda změřit na porovnání dibi (minified verze) a mezi memory usage před a těsně po "dibi::connect" je rozdíl skoro 2MB, což mi přijde docela mazec, takže možná přece jen nic tak špatně nemám ... jelikož můžu být lama, ale DGX asi ne (aspoň relativně)

Nebylo by asi od věci nacpat ten základ od třídy do paměti, ale ikdyby to šlo tak věci jako memcached třeba na hostinzích zrovna běžné nebudou (u toho mého tedy není ani se neplánuje....je to tedy pochopitelné)

Nevím jak až moc jsou vyšší nároky závadné...memory_limit na hostingu mám 32MB což je rezerva ještě velká, ale hrotit to nadoraz by se taky nemuselo, proč to neudělat efektivnější, že (pokud je to v rámci OO v PHP možné)

Hledal jsem po googlu, ale nemůžu nic najít tak se obracím sem

Díky

Majkl578:
„Ten rozdíl 2MB je při načtení knihovny, ne při připojení. Viz můj minitest.“
Tak jsem to myslel.... to načtění jsem použil kvůli autoloadu, promiň za nepřesnost

bylo by zajímavý zjistit, kolik zabírají podobné řešení, jedno v OOP a jedno procedurálně,
nevim jestli něco takovýho existuje