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

 
 

You are not allowed to post comments on this tracker with your current authentification level.

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

Submitted by:  Wolfgang Sourdeau <wolfgang>
Submitted on:  Wed 03 Oct 2012 01:34:58 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: Declined

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>
Project 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>
Project 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>

 

Attached Files
file #26688:  nsnumberaskey.m added by wolfgang (4kB - 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
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by wolfgang (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 03 Oct 2012 02:00:31 PM UTCCaSStatusNone=>Invalid
      Open/ClosedOpen=>Declined
    Wed 03 Oct 2012 01:34:58 PM UTCwolfgangAttached File-=>Added nsnumberaskey.m, #26688

    Back to the top


    Powered by Savane 3.1-cleanup