Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28395 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11109 invoked by uid 1010); 18 Mar 2007 15:39:53 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 11094 invoked from network); 18 Mar 2007 15:39:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2007 15:39:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 212.112.227.169 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 212.112.227.169 ipx11223.ipxserver.de Linux 2.5 (sometimes 2.4) (4) Received: from [212.112.227.169] ([212.112.227.169:36192] helo=ipx11223.ipxserver.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 28/37-35706-74D5DF54 for ; Sun, 18 Mar 2007 10:39:53 -0500 Received: from localhost (localhost [127.0.0.1]) by ipx11223.ipxserver.de (Postfix) with ESMTP id D9FA6DF00D8; Sun, 18 Mar 2007 16:39:48 +0100 (CET) Received: from ipx11223.ipxserver.de ([127.0.0.1]) by localhost (flottensignalgeber [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08032-03; Sun, 18 Mar 2007 16:39:46 +0100 (CET) Received: from [127.0.0.1] (206.103.76.83.cust.bluewin.ch [83.76.103.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ipx11223.ipxserver.de (Postfix) with ESMTP id 86985DF0009; Sun, 18 Mar 2007 16:39:46 +0100 (CET) Message-ID: <45FD5D41.8020907@pooteeweet.org> Date: Sun, 18 Mar 2007 17:39:45 +0200 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?UTF-8?B?QmFua8OzIMOBZMOhbQ==?= Cc: internals@lists.php.net References: <1174134488.8667.33.camel@lena> <45FC74A5.6080307@pooteeweet.org> <1174231834.12274.110.camel@lena> In-Reply-To: <1174231834.12274.110.camel@lena> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by somedaemon at backendmedia.com Subject: Re: [PHP-DEV] google SoC - dbobj From: mls@pooteeweet.org (Lukas Kahwe Smith) Bankó Ádám wrote: > Pure C code has access to PHP5's low level object API, so it can produce > a really intuitive interface (object persistence), that you can't do > from PHP code. C code uses a bit less memory and a lot less CPU time I would hope that the solution for "low level object API" would be that we expose more and more of that to user space. Stuff like being able to force the calling of the parent constructor come to mind, I am sure there are other things more relevant to the topic at hand as well. But yes, its a valid point. > The other issue is performance. For the ORM field I didn't find > operation that could be moved out to native code efficiently. Most > complex operations need a lot of data, and passing this data to a native > function, doing decoding and after it's processed the time needed for > recoding would eliminate the performance benefit. For example ADODB > could implement the resultset_to_array method in C, because there's > minimal overhead on fetching a row from a database resource (negative > compared to it's PHP equivalent). Yeah, you are right .. it might be hard to find things that can be moved to C space and vice versa. I do not know where to draw the line this very second either. I just want to make sure that this option is explored. I remember that Thies once said, the ultimate goal of the PHP language would be to make everything fast enough in PHP so that everything can be done in user space. All the extension should do is expose third party libs. Of course this might only be a dream, but I think its one of those dreams worth purseing .. even if you never make it. regards, Lukas