Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:247 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70459 invoked from network); 25 Mar 2003 08:13:52 -0000 Received: from unknown (HELO wmeler.t1.gda.wp-sa.pl) (212.77.105.136) by pb1.pair.com with SMTP; 25 Mar 2003 08:13:52 -0000 Received: (from wmeler@localhost) by wmeler.t1.gda.wp-sa.pl (8.11.6/8.11.6) id h2P8Cft19176; Tue, 25 Mar 2003 09:12:41 +0100 X-Authentication-Warning: wmeler.t1.gda.wp-sa.pl: wmeler set sender to wmeler@wp-sa.pl using -f Date: Tue, 25 Mar 2003 09:12:41 +0100 To: Andi Gutmans Cc: zeev@zend.com, internals@lists.php.net Message-ID: <20030325091241.G31290@wp-sa.pl> Reply-To: wmeler@wp-sa.pl References: <3b6af3b7d2.3b7d23b6af@wp-sa.pl> <5.1.0.14.2.20030324232410.02b876c8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20030324232410.02b876c8@127.0.0.1>; from andi@zend.com on Mon, Mar 24, 2003 at 11:25:47PM +0200 Subject: Re: [PHP-DEV] ZTS performance From: wmeler@wp-sa.pl (Wojtek Meler) On Mon, Mar 24, 2003 at 11:25:47PM +0200, Andi Gutmans wrote: > At 10:20 PM 3/24/2003 +0100, wmeler@wp-sa.pl wrote: > > > ZTS is *always* going to be slower than non ZTS. > > > >Yes, but it can be faster than it is. PHP doesn't use almost any shared > >resources (compiled regexs?) so why it is so slow ? Thread-safe syscalls > >? I don't think so. > > Hmm, not worth arguing with you if you're so sure you know how PHP doesn't > need any per-thread resources. It does... You didn't understand me (my english isn't perfect and there are lacks in vocabulary). PHP uses almost only per-thread resources - global, but only for thread resources. It doesn't use process-global resources (I found only compiled regex cache) so it doesn't need to synchronize on them. There are no lock-contention problems in PHP. > I'm not sure how __thread works but the TSRM implementation already uses > thread local storage to cache the per-thread objects. Not sure __thread > doesn't do the same. as Sascha said - NPTL is the future for multi-threaded applications - I think there is a need for review of TSRM. Regards, Wojtek