Hi I really liked your post, it captures the feeling where you were walking down a path, feeling fine and suddenly you open a door... and find that all the time you've been in an underground tunnel!
On Wed, Feb 3, 2010 at 2:39 AM, Delifisek Tux <delifisek....@gmail.com> wrote: > WTF !?? > > How can they wrote web apps when there where no $_REQUEST or equal... > > After some them you realize PHP was something very very very WEB programming > oriented. here. a _lot_ of things that you thought 'sure, of course..' were in fact PHP-specific things. there are other ways to do them. > Then big question is poping up. > > In PHP world, Framework means SLOW. A decent framework eats up your %50 of > cpu resource. For example that Uber Zend FW gives you 1/6 in a hello world > app comparing plain php. > > When you seeing this kind of question. > > It means How FAST is ? > > Basically we know python lot faster than PHP. But we don't know how how > Django eats resources (or is it eating lot resources like php frameworks). and the answer is.... that it's the wrong question yes, python is faster than PHP; but not astoundingly so. (i'd love to do web development in Lua/LuaJIT, now _that_ is fast!) it's that it works different from PHP. the biggest difference is that PHP is mostly run only in the request/response cycle. in most cases, it's compiled from source code _on_each_and_every_request_. Even with PHP accelerators/caches that keep the already-parsed code in memory, it still starts with a fresh, empty environment for every web hit. therefore, a PHP framework has to do _all_ the initialization work every time. and that costs. a lot with general purpose programming languages (like python, or ruby; heck, even Java), you don't have a pre-defined god-sent request/response cycle. you program that too. and that means, you can do things _before_ being asked! for example, Django's ORM reads all its structures from your 'model' files, and creates nice classes at runtime. It's runtime, but more precisely start-time. that is, before the first request. when you get a request, you have the data objects ready to do any needed DB querying. another issue is cacheing, there are _lots_ of opportunities for cache, at many different levels. most of them are easy to do simply because the framework's code stays up and running from one request to the other. that means, a well-coded framework can be extensive, sophisticated, even heavy; but still perform very quickly. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
