Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93928 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86556 invoked from network); 13 Jun 2016 09:40:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jun 2016 09:40:46 -0000 Authentication-Results: pb1.pair.com header.from=pthreads@pthreads.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=pthreads@pthreads.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.213.53 cause and error) X-PHP-List-Original-Sender: pthreads@pthreads.org X-Host-Fingerprint: 209.85.213.53 mail-vk0-f53.google.com Received: from [209.85.213.53] ([209.85.213.53:34856] helo=mail-vk0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A8/98-12403-E9F7E575 for ; Mon, 13 Jun 2016 05:40:46 -0400 Received: by mail-vk0-f53.google.com with SMTP id d127so171187444vkh.2 for ; Mon, 13 Jun 2016 02:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pthreads-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QEO/G7WjZ4rBSxmWPzS+Vbexg+w/0fT08KWv8I1mRLY=; b=IAdB8PT9colb23m5MB+AzHkAinZT8Tsm0xdaxV4ip0H48X7JUwRRYp6qy7XW7RTSi/ 6pdPsflyrSAvDmvLOSPedtLBxMi0NQuyYxFL8g8FeoBfd/XDpGq7Of55E9QIt/WAXxXt YDIBhsxGFQAeZcw356LvlK3qeuaFBON29rVhWCyQVkqpsHiyWviez8ncwJEWg88hcILQ rkIVE6TYzO5GBNdzENhz3TZgBzunYLU1xNekUqdtLdHj0T5vUT/DLUq6FFPmOCpP2Rnw SOcMe/i4KfcIFUmOSWjdSuQ0zGAy/xjXT1q5mcS4XrHwXMgbumklrhoyWFOhDGv2rueZ j0nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QEO/G7WjZ4rBSxmWPzS+Vbexg+w/0fT08KWv8I1mRLY=; b=UfQy6yzGdDk6/VySlezAPvj4+1kt/cEh27bv2PxgDv3NKepsQZucukZL7ahEvKOquU yBaGyPjJb+JcaGPD+UenyHWfSaOazzCGLT9zjHH0lMQwlpKIwF1g64XsH1fSiuMSXN4p c2sDO15Rv+EwJ1qhMTnmNFhT2gHh8HHVJ0tO+EmkeiBvEEZlcevfVupJcVGzFdaaz0xV o8f3zhXF00LoTCZrgxWi79rYmK4dFn9uqoxk1J/frlwYAAekVnSbcB1E5f4mq7NY2s3m hO+WgpyglS+8LoEsWOoRxzhQyWxKOyKgHkSGUcFYYP2q81HlLeMHEUBtqTk9Uwg0br7P n9sw== X-Gm-Message-State: ALyK8tKdpeniBfl7UictFtwLjqHs6A2xFkNccnQGxM1i45ICIQlryR0BP+aU36kfY57oD+5QqmP5k/tLwn+/Hw== MIME-Version: 1.0 X-Received: by 10.176.2.242 with SMTP id 105mr5784774uah.151.1465810843304; Mon, 13 Jun 2016 02:40:43 -0700 (PDT) Received: by 10.103.47.199 with HTTP; Mon, 13 Jun 2016 02:40:43 -0700 (PDT) X-Originating-IP: [109.157.60.99] In-Reply-To: References: Date: Mon, 13 Jun 2016 10:40:43 +0100 Message-ID: To: Rasmus Schultz Cc: Yasuo Ohgaki , Dmitry Stogov , PHP internals , Phil Sturgeon Content-Type: multipart/alternative; boundary=001a1142e5509f9c60053525aeb7 Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: pthreads@pthreads.org (Joe Watkins) --001a1142e5509f9c60053525aeb7 Content-Type: text/plain; charset=UTF-8 Morning, > This wouldn't affect the performance of untyped properties at all. There are extra instructions in that code. When the code you have is only 5 instructions, adding 1 more instruction makes a 20% increase in instructions ... That is what we are looking at in these micro benchmarks; The number of instructions is so small, that even the small difference is measurable. Of course you can measure the difference, and obviously there are going to be more instructions, but we should only care about what effects real world code. This doesn't effect real world code. Cheers Joe On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz wrote: > Pretend I know (basically) nothing about how PHP was implemented, because > I don't ;-) > > But I don't understand why regular property updates should be affected by > this at all? > > If I had to implement type-checked properties in plain PHP, I would do > something like this... > > /** > * @property int $price > */ > class Product > { > private $_price; > > public function __set($name, $value) { > if ($name === "price") { > if (!is_int($value)) { > throw new UnexpectedValueException("..."); > } > $this->_price = $price; > return; > } > throw new RuntimeException("undefined property {$name}"); > } > > public function __get($name) { > return $this->{"_{$name}"}; > } > } > > I would have guessed an implementation of type-checked properties would > work in much the same way. > > Of course, it wouldn't use "_" as a prefix for the underlying property, > but some other magic byte, much like how private properties are internally > prefixed with a magic byte, right? > > This wouldn't affect the performance of untyped properties at all. > > Of course typed property writes would be more expensive, but that's to be > expected. > > > On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki wrote: > >> Hi Dmitry, >> >> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov wrote: >> > I hardly worked on implementation of this patch for a week, but I still >> don't like it. >> > >> > It makes 15% slowdown on each property update in existing PHP code >> (without types), and I don't see a way to improve this. >> > >> > Update of typed properties is going to be even more expensive. >> > >> > Benchmark results are included into RFC (and not changed with the >> latest version of the patch). >> > >> > >> > -1. >> >> If we are concerned about performance, DbC would be the only solution >> for this kind of problem. i.e. Validate fully during development, do >> minimum validation on production. DbC helps type inference also. There >> may not be enough time for discussion, but do you think there is >> enough time for implementation? I suppose implementation is >> straightforward, so it might be OK to have RFC w/o implementation. We >> have 2 options anyway. It's waste of time for having 2 >> implementations. Would you like to proceed the RFC for 7.1? >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohgaki@ohgaki.net >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > --001a1142e5509f9c60053525aeb7--