Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26499 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 66106 invoked by uid 1010); 10 Nov 2006 23:23:13 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 66091 invoked from network); 10 Nov 2006 23:23:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Nov 2006 23:23:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain php.net from 81.169.182.136 cause and error) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6 Received: from [81.169.182.136] ([81.169.182.136:56855] helo=strato.aixcept.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 63/23-27611-0E905554 for ; Fri, 10 Nov 2006 18:23:12 -0500 Received: from baumbart.mbo (dslb-084-063-045-138.pools.arcor-ip.net [84.63.45.138]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by strato.aixcept.de (Postfix) with ESMTP id 5823261028C; Sat, 11 Nov 2006 00:23:09 +0100 (CET) Date: Sat, 11 Nov 2006 00:24:00 +0100 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <10310025678.20061111002400@marcus-boerger.de> To: Sebastian Bergmann Cc: internals@lists.php.net In-Reply-To: References: <4554AE0D.4080600@caedmon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Hash Algorithm [was: Re: [PHP-DEV] Namespaces in PHP 6 - ++$take] From: helly@php.net (Marcus Boerger) Hello Sebastian, the best ones unfortunatley are GPL and thus not acceptable. I once played with case insensitive hashes. They worked very much faster - but they had more conflicts. If we were about intel processors my experience is that string functions can be optimized at assembler level very much. For instance i once ago increased string up/downcase by 32 times using a table based xlat approach that was reading the string in chunks of 4 byte. Maybe itcould be interesting to see whether we could come up with a version that takes 4 byte or 8 byte chunks depending on the cpu. And eventually we have hash codes in 64 bit machines be 8 bytes long as well. best regards marcus Friday, November 10, 2006, 7:20:59 PM, you wrote: > Ilia Alshanetsky wrote: >> As your key size increases the slower the key hash generation process >> becomes, if you look at the PHP's hash key generation code you'll see >> that it works best for 8 or less chars, anything longer and the >> performance starts to drop. > It's been a long time since I studied hashes: are there no hashing > algorithms that perform better with more than 8 characters? > -- > Sebastian Bergmann http://sebastian-bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 Best regards, Marcus