php-general Digest 12 Dec 2010 06:24:05 -0000 Issue 7082
Topics (messages 309962 through 309963):
Announcing New PHP Extension: FileConv
309962 by: Daniel Brown
Re: ORM doctrine
309963 by: Tommy Pham
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Happy Saturday, folks;
I've finally gotten around to releasing my latest PHP extension
(which was actually written about two years ago). Named FileConv, it
adds native functions for converting back and forth between DOS, *NIX,
and legacy MacOS file formats. It's compact, comes with a basic
installer, and can convert a 1MB text file to/from any of the included
formats in approximately one-tenth of one second. Unlike many
versions that you could otherwise use from the command line, this
library allows the file to retain its original timestamps, as well.
I ran through some recursive directories of files with a test
script, determining which files were text versus which were binary,
detected the formatting of the text files, and converted to a
different format at random (if Mac, go to DOS/*NIX, if *NIX, go to
Mac/DOS, etc.). Approximately 1.5GB of files were scanned, detected,
and translated, with a cost of 1 minute 24 seconds.
You can read more about the library and download it yourself at
http://links.parasane.net/n4c4 . After doing some code cleanup when I
have time, the next step will be continuing with the process of
getting it into PECL, as was initially planned two years ago.
--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Peter Lind [mailto:[email protected]]
> Sent: Saturday, December 11, 2010 6:24 AM
> To: Tommy Pham
> Cc: php-general List
> Subject: Re: [PHP] ORM doctrine
>
> On Friday, 10 December 2010, Tommy Pham <[email protected]>
> wrote:
>
> * snup *
>
> > The way I see it is this:
> >
> > 1) Thorough understanding of the problem: needs of the client/company,
> > programming language in use, etc.
> > 2) Thorough understanding of the objective of the application: answer
> > the needs, capable of possible future growth/expandability, etc.
> > 3) Well thought out application design to resolve the above 2:
> > framework, mixed, or no framework.
> >
> > Thus, IMHO, caching is needed when one fails to fully meet the above 3
> > such as when the user clicks on any link in the browser, it should
> > take no more than 3 seconds for the browser's status to be 'Done',
> > provided that the user isn't on some 56k modem connection ;).
>
> Always use a cache. Not using a cache means you've misunderstood some
> fundamental points.
>
> Regards
> Peter
>
>
> --
> <hype>
> WWW: plphp.dk / plind.dk
> LinkedIn: plind
> BeWelcome/Couchsurfing: Fake51
> Twitter: kafe15
> </hype>
I understand cache well, both the benefits (save DB trip) and shortfalls
(outdated by DB, management, etc.). Most of the apps that I've seen so far
used cache to solve a problem that shouldn't happen in the 1st place. For
example, during recent my quest looking PHP MVC framework and sample apps, I
saw OpenCart, an e-commerce app based on custom MVC framework. Installed it
for a test run. It looks good and seems to perform well with the included
sample data. Then I filled up some more sample data: over 3000 categories,
over 2000 manufacturers, over 300,000 products. No other changes made such
specials, features, etc. Although the app supports i18n, the sample data is
just one language for a decent DB size of about 100MB. The app took over 30
seconds to respond for any link. Then I disable the cache and began debugging.
I made 1 minor addition to the DB and 1 minor change in the code base - parts
on 1 line - I shorten the response time by about 10 seconds. What I just did
proved my 2nd and 3rd point :)
Regards,
Tommy
--- End Message ---
