Re: Is opening a new source file really costly? Was: [PEPr] Comment on RFC::Package naming, file naming and directory structure RFC
| From: | Alan Knowles | Date: | Tue, 20 Apr 2004 13:47:40 +0000 |
| Subject: | Re: Is opening a new source file really costly? Was: [PEPr] Comment on RFC::Package naming, file naming and directory structure RFC | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-28142@lists.php.net to get a copy of this message | ||
Sergio Carvalho wrote:
Sorry if I'm being obnoxious. I'll insist a bit more, since I still don't get it. On the bug you presented, the culprit was the loading of Date.php. Looking at the file, we see it is 36KB long. I'd expect parse and compile time to be significant on that one (0.3s on the bug case). I'd expect parse and compile time to grow linearly with the code size, not file count, as was proposed by Daniel Convissor: http://aspn.activestate.com/ASPN/Mail/Message/pear-dev/2055682 Am I wrong?Not totally, The point being, without a cache, if you are worried about performance, then you are not really looking at the problem correctly. The bug report pointed out that as soon as you introduce a cached compiler, the number and size of files becomes so negligable performance wise, that it's not really an issue.. What you then get down to is where the balance is on - easy to understand/read.. - maintainable - extendable.. AFAIK, caches can usually also be tuned to not even do stat's on the filesystem. - so the fact it is in multiple files becomes totally irrelivant after a while. Regards Alan
Cheers, Sérgio Carvalho Alan Knowles wrote:-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.comThis illustrates the issue and the solution quite well.. http://pear.php.net/bugs/bug.php?id=1127 Regards Alan