bugGNUstep - Bugs: bug #37494, Performance issue with NSNumber...

Group
 
 

bug #37494: Performance issue with NSNumber when used as key in an NSDictionary

Submitter:  Wolfgang Sourdeau <wolfgang>
Submitted:  Wed 03 Oct 2012 01:34:58 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Declined
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 03 Oct 2012 02:28:49 PM UTC, comment #4: 


> Did your computer start swapping during the process?


I don't think so, buyt just to be sure I made a version of the code which used the original size of dictionary, and just repeated the populating/fetching loops a thousand times:

2012-10-03 15:19:00.213 nsnumberaskey-1[9796] populating dict (low NSNumber)
2012-10-03 15:19:45.238 nsnumberaskey-1[9796] end population of dict
2012-10-03 15:19:45.238 nsnumberaskey-1[9796] fetching values
2012-10-03 15:20:23.373 nsnumberaskey-1[9796] fetched values
2012-10-03 15:20:23.439 nsnumberaskey-1[9796] populating dict (high NSNumber)
2012-10-03 15:21:08.972 nsnumberaskey-1[9796] end population of dict
2012-10-03 15:21:08.972 nsnumberaskey-1[9796] fetching values
2012-10-03 15:21:48.132 nsnumberaskey-1[9796] fetched values
2012-10-03 15:21:48.304 nsnumberaskey-1[9796] populating dict (NSString)
2012-10-03 15:22:23.408 nsnumberaskey-1[9796] end population of dict
2012-10-03 15:22:23.409 nsnumberaskey-1[9796] fetching values
2012-10-03 15:22:52.280 nsnumberaskey-1[9796] fetched values

Richard Frith-Macdonald <CaS>
Group Member
Wed 03 Oct 2012 02:18:15 PM UTC, comment #3: 

Regarding my last comment, the 15 seconds seem to occur during the population of the array. Fetching the keys does take 3 secs, so it makes sense. The 15 seconds might be due to the fact that the dictionary is rehashes a couple of times.

Therefore this issue can indeed be considered closed.

Wolfgang Sourdeau <wolfgang>
Wed 03 Oct 2012 02:08:12 PM UTC, comment #2: 

Well... For the version you are using this would be a different issue then, but it clearly should not take 15 seconds for this amount of entries.

With 10000000 I seem to lack memory to complete the test.
With 1000000, it uses 230ms. Logically, if the difference is exponential, it would take about 2.5 to 3 secs for the number you use, not 15.

Did your computer start swapping during the process?

Wolfgang Sourdeau <wolfgang>
Wed 03 Oct 2012 02:00:31 PM UTC, comment #1: 

Thanks for the report, but I can't reproduce any problem ...

With the original test program, the test run was too short to give any sort of reliable indication of the speeds of the different operations, so I increaed the 'maxkeys' define to 10000000 (two orders of magnitude larger):

2012-10-03 14:48:30.371 nsnumberaskey[553] populating dict (low NSNumber)
2012-10-03 14:48:45.139 nsnumberaskey[553] end population of dict
2012-10-03 14:48:45.415 nsnumberaskey[553] fetching values
2012-10-03 14:48:48.778 nsnumberaskey[553] fetched values
2012-10-03 14:48:57.487 nsnumberaskey[553] populating dict (high NSNumber)
2012-10-03 14:49:12.126 nsnumberaskey[553] end population of dict
2012-10-03 14:49:12.127 nsnumberaskey[553] fetching values
2012-10-03 14:49:16.114 nsnumberaskey[553] fetched values
2012-10-03 14:49:39.502 nsnumberaskey[553] populating dict (NSString)
2012-10-03 14:50:09.438 nsnumberaskey[553] end population of dict
2012-10-03 14:50:09.438 nsnumberaskey[553] fetching values
2012-10-03 14:50:12.757 nsnumberaskey[553] fetched values

There's clearly no significant performance difference between small and large numbers here.

Perhaps the original problem was on an old version of gnustep, or some other issue was causing it?



Richard Frith-Macdonald <CaS>
Group Member
Wed 03 Oct 2012 01:34:58 PM UTC, original submission:  

When using NSNumber as key in a NSDictionary, the performance is acceptable with low values. With very high unsigned long long values, the performance drop seriously.

Here is the output of the enclosed test program.

2012-10-03 09:27:28.338 nsnumberaskey[23007] populating dict (low NSNumber)
2012-10-03 09:27:28.368 nsnumberaskey[23007] end population of dict
2012-10-03 09:27:28.369 nsnumberaskey[23007] fetching values
2012-10-03 09:27:28.386 nsnumberaskey[23007] fetched values
2012-10-03 09:27:28.414 nsnumberaskey[23007] populating dict (high NSNumber)
2012-10-03 09:27:31.490 nsnumberaskey[23007] end population of dict
2012-10-03 09:27:31.490 nsnumberaskey[23007] fetching values
2012-10-03 09:27:34.594 nsnumberaskey[23007] fetched values
2012-10-03 09:27:34.649 nsnumberaskey[23007] populating dict (NSString)
2012-10-03 09:27:34.711 nsnumberaskey[23007] end population of dict
2012-10-03 09:27:34.713 nsnumberaskey[23007] fetching values
2012-10-03 09:27:34.737 nsnumberaskey[23007] fetched values

The "low NSNumber" and NSString tests use keys with a value from 0 to 100000. The high NSNumber case use keys from (1<<63 - 0) to (1 << 63 - 100000).

Wolfgang Sourdeau <wolfgang>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #26688:  nsnumberaskey.m added by wolfgang (4KiB - application/octet-stream - test program illustrating the bug)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by wolfgang (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-10-03 CaS StatusNone Invalid
        Open/ClosedOpen Declined
    2012-10-03 wolfgang Attached File- Added nsnumberaskey.m, #26688

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code