Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66617 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33297 invoked from network); 14 Mar 2013 16:14:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Mar 2013 16:14:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.91 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.91 blu0-omc2-s16.blu0.hotmail.com Windows 2000 SP4, XP SP1 Received: from [65.55.111.91] ([65.55.111.91:12056] helo=blu0-omc2-s16.blu0.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9F/24-07586-D47F1415 for ; Thu, 14 Mar 2013 11:14:05 -0500 Received: from BLU0-SMTP195 ([65.55.111.71]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Mar 2013 09:14:03 -0700 X-EIP: [k/aH45x2KZiWjANOVqz9nuT6sWkQKcxk] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Received: from [192.168.178.30] ([78.141.134.76]) by BLU0-SMTP195.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Mar 2013 09:14:01 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) In-Reply-To: Date: Thu, 14 Mar 2013 17:13:58 +0100 CC: PHP Developers Mailing List Content-Transfer-Encoding: quoted-printable References: To: Lazare Inepologlou X-Mailer: Apple Mail (2.1499) X-OriginalArrivalTime: 14 Mar 2013 16:14:01.0101 (UTC) FILETIME=[F08653D0:01CE20CE] Subject: Re: [PHP-DEV] feature request : easy shared memory From: bobwei9@hotmail.com (Bob Weinand) Am 14.3.2013 um 16:46 schrieb Lazare Inepologlou : > Hello, >=20 > 2013/3/14 rene7705 >=20 >> great! :) >>=20 >> this will do nicely. is there much overhead for storing and fetching = these >> variables? (ideally I would like to get a pointer) >>=20 >>=20 > Unfortunately there is. Every object stored in APC has to be = serialised > first and then unserialised on retrieval. You can improve performance = by > using a binary serialiser (such as igBinary) instead of the default = php one. >=20 >=20 >=20 >=20 >>=20 >> On Thu, Mar 14, 2013 at 12:45 PM, Nikita Nefedov >> wrote: >>=20 >>> On Thu, 14 Mar 2013 07:05:03 -0000, rene7705 = wrote: >>>=20 >>> Hi. >>>>=20 >>>> I'd like to build a replacement for SQL (yes, talk about an = ambitious >>>> project! ;), because the constant transferal of data in and out of = SQL >>>> from >>>> Javascript (where everything might as well be object-oriented and >>>> hierarchial) is a pain in the neck. >>>>=20 >>>> But in order to do so, I'd very much like PHP (the server still = controls >>>> the data after all) to support shared memory efficiently. >>>>=20 >>>> Something like >>>>=20 >>>> sharedmem $bigNestedArray; // $bigNestedArray would be shared = accross >> the >>>> entire server and all CPUs on it. >>>>=20 >>>> as you now have >>>>=20 >>>> global $bigNestedArray; >>>>=20 >>>> would be ideal. >>>>=20 >>>> I bet this would be useful for a host of other applications as = well, and >>>> fairly easy to implement. >>>>=20 >>>> I'm an application programmer by trade, or I would hack this in = myself. >>>>=20 >>>> I'd much rather see the PHP development team develop this in = properly. I >>>> don't think it would require much time, as OS-level shared memory = has >> been >>>> easy to implement since the 1990s. >>>>=20 >>>> Please put this on the agenda, and get back to us in this thread as = to >>>> when >>>> this will be available. >>>>=20 >>>=20 >>> Hi, >>>=20 >>> You can already do it using APC's apc_store() and apc_fetch() = functions >>> which let you use shared memory. But of course you should 'commit' = every >>> change of the fetched variable. >>>=20 >>=20 >=20 >=20 > Lazare INEPOLOGLOU > Ing=E9nieur Logiciel Hi! And there is no possibility to store the zval as raw binary data like in = memory (deep copy?) So that you only have to copy from ram? And replace the pointers to the = place in the string? This must be possible I think. And should be faster. shmop has to be opened on every request and only supports strings. APC, memcache,... can only save under serialized form which is slow. Why not integrate some native shared memory mechanism which is faster = than the extensions which always serialize? (or as a new extension=85 but I really like the = proposal to do like "shared $var;" which is (nearly) impossible as an extension) Bob Weinand=