bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #8365] -[NSString hash] limitation makes dictionaries horribly hor


From: Richard Frith-Macdonald
Subject: [bugs #8365] -[NSString hash] limitation makes dictionaries horribly horribly slow
Date: Wed, 31 Mar 2004 06:41:04 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #8365] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Wed 03/31/04 at 11:41 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Fixed in CVS ... I think it made sense to limit this for general performance in 
the past, but we now cache the hash values for strings (apart from constant 
strings) so the performance trade-off is probably in favour of using all
characters now.
For short strings this should make no difference.






/**************************************************************************/
[bugs #8365] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8365>
Project: GNUstep
Submitted by: Larry Campbell
On: Tue 03/30/04 at 04:46

Category:  Base/Foundation
Severity:  5 - Average
Item Group:  Bug
Resolution:  Fixed
Assigned to:  None
Status:  Closed


Summary:  -[NSString hash] limitation makes dictionaries horribly horribly slow

Original Submission:  For some reason not explained in any comments I could 
find, -[NSString hash] ignores all but the first 63 bytes of a string. This 
means that if you're storing large strings in an NSDictionary, your performance 
is completely hosed. I just removed the 63-byte truncation, and an operation 
that used to take 20 to 30 minutes now takes only seconds -- two to three 
orders of magnitude faster.

What is the reason, if any, for this limitation? Shouldn't it be removed?


Follow-up Comments
------------------


-------------------------------------------------------
Date: Wed 03/31/04 at 11:41         By: CaS
Fixed in CVS ... I think it made sense to limit this for general performance in 
the past, but we now cache the hash values for strings (apart from constant 
strings) so the performance trade-off is probably in favour of using all
characters now.
For short strings this should make no difference.




CC List
-------

CC Address                          | Comment
------------------------------------+-----------------------------
lcampbel --AT-- akamai --DOT-- com  | 









For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8365>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]