On 5/29/13, Charles Srstka cocoa...@charlessoft.com wrote:
On May 29, 2013, at 10:29 PM, Eric Wing ewmail...@gmail.com wrote:
But I did do hash table benchmarks a few months back:
http://playcontrol.net/opensource/LuaHashMap/benchmarks.html
Perhaps off topic, but I wonder if it would be
On 5/29/13, Jens Alfke j...@mooseyard.com wrote:
On May 29, 2013, at 8:29 PM, Eric Wing ewmail...@gmail.com wrote:
CFDictionary I did not formally do in the benchmark, but I did run on
the side for curiosity. I found that the C-string to CFString
conversion ended up putting it at the bottom
Le 30 mai 2013 à 08:35, Eric Wing ewmail...@gmail.com a écrit :
On 5/29/13, Jens Alfke j...@mooseyard.com wrote:
On May 29, 2013, at 8:29 PM, Eric Wing ewmail...@gmail.com wrote:
CFDictionary I did not formally do in the benchmark, but I did run on
the side for curiosity. I found that
On 30 May 2013, at 12:33, Jens Alfke j...@mooseyard.com wrote:
On May 29, 2013, at 6:30 PM, Ian Joyner ianjoy...@me.com wrote:
That seems to come out of a belief that well-structured code is code that
runs poorly
No, it’s a paraphrase of a famous quote by Don Knuth (We should forget
On May 30, 2013, at 3:52 AM, Ian Joyner ianjoy...@me.com wrote:
What I am trying to point out though is that there is a misapprehension that
premature optimization means writing structured code early on so don't
structure it because you can always go and clean it up later. Rather I think
On May 29, 2013, at 11:35 PM, Eric Wing ewmail...@gmail.com wrote:
In my introduction, I was fairly adamant that time lost to impedance
mis-match should be measured because my interest was real performance
in using these libraries for projects based in C. That conversion time
is non-trivial.
On May 30, 2013, at 3:52 AM, Ian Joyner ianjoy...@me.com wrote:
What I am trying to point out though is that there is a misapprehension that
premature optimization means writing structured code early on so don't
structure it because you can always go and clean it up later. Rather I think
On 5/30/13, Jens Alfke j...@mooseyard.com wrote:
On May 29, 2013, at 11:35 PM, Eric Wing ewmail...@gmail.com wrote:
In my introduction, I was fairly adamant that time lost to impedance
mis-match should be measured because my interest was real performance
in using these libraries for projects
On 31 May 2013, at 01:43, Jens Alfke j...@mooseyard.com wrote:
On May 30, 2013, at 3:52 AM, Ian Joyner ianjoy...@me.com wrote:
What I am trying to point out though is that there is a misapprehension that
premature optimization means writing structured code early on so don't
structure it
On May 28, 2013, at 5:55 PM, Greg Parker wrote:
On May 28, 2013, at 3:39 PM, Michael Hall mik3h...@gmail.com wrote:
On May 28, 2013, at 5:27 PM, Michael Hall wrote:
I thought I saw SHA-1 being used as a general purpose hash function
somewhere sort of surprising recently but I'm not
Le 29 mai 2013 à 00:46, Graham Cox graham@bigpond.com a écrit :
On 28/05/2013, at 3:46 PM, Oleg Krupnov oleg.krup...@gmail.com wrote:
I'd like to have a dictionary using C strings as keys (because I
already have const char* strings and would like to spare on creating
NSString
Le 29 mai 2013 à 06:14, Oleg Krupnov oleg.krup...@gmail.com a écrit :
Why not just create NSString wrappers? By using the
-initWithBytesNoCopy:length:encoding:freeWhenDone: method you can avoid it
copying the actual C string characters, it literally just becomes a thin
wrapper.
In my
On May 28, 2013, at 9:14 PM, Oleg Krupnov oleg.krup...@gmail.com wrote:
The profiler is not a panacea; when you have hundreds of small,
not-so-efficient pieces of code like this, all you see in profiler is a long
list of small consumers, totaling in heavy use of objc runtime calls.
Oh,
On May 28, 2013, at 9:14 PM, Oleg Krupnov oleg.krup...@gmail.com wrote:
The code in question is frequently used in many places so I think it's worth
optimization.
Did you actually profile the app and find that a lot of time is spent in this
code?
While I generally agree that premature
On 29 May 2013, at 14:14, Oleg Krupnov oleg.krup...@gmail.com wrote:
While I generally agree that premature optimization is evil,
That seems to come out of a belief that well-structured code is code that runs
poorly (this belief came out of an IBM system of the 50s/60s that had really
poorly
On May 29, 2013, at 6:30 PM, Ian Joyner ianjoy...@me.com wrote:
That seems to come out of a belief that well-structured code is code that
runs poorly
No, it’s a paraphrase of a famous quote by Don Knuth (We should forget about
small efficiencies, say about 97% of the time: premature
I'm not disagreeing with anything about knowing/optimizing your real
bottlenecks.
But I did do hash table benchmarks a few months back:
http://playcontrol.net/opensource/LuaHashMap/benchmarks.html
CFDictionary I did not formally do in the benchmark, but I did run on
the side for curiosity. I
On May 29, 2013, at 10:29 PM, Eric Wing ewmail...@gmail.com wrote:
But I did do hash table benchmarks a few months back:
http://playcontrol.net/opensource/LuaHashMap/benchmarks.html
Perhaps off topic, but I wonder if it would be possible to alter your line
charts so that those circles that
On May 29, 2013, at 8:29 PM, Eric Wing ewmail...@gmail.com wrote:
CFDictionary I did not formally do in the benchmark, but I did run on
the side for curiosity. I found that the C-string to CFString
conversion ended up putting it at the bottom of the list in terms of
performance.
It seems
On May 27, 2013, at 10:46 PM, Oleg Krupnov oleg.krup...@gmail.com wrote:
Now, the problem is that sometimes when I try to get a value from the
table, the MapTableKeyComparator function is not called at all, and
NSMapGet returns NULL, thought immediate dump of the table shows that
all
Hi Jens,
I guess you may be right. But… two questions in this regard:
1. I thought that isEqual method is alternative to hash method,
because searching by key and searching by hash are two mutually
exclusive methods of looking up values, aren't they?
2. What hash function you'd suggest in my
Cryptographic hashes such as md5 are intensive to calculate because
they are meant to make it difficult for an attacker to come up with
different inputs that output identical hashes.
For purposes of looking up strings in a hash table, a 32 bit CRC
(Cyclic Redundancy Check) would be quick to
Le 28 mai 2013 à 08:25, Oleg Krupnov oleg.krup...@gmail.com a écrit :
Hi Jens,
I guess you may be right. But… two questions in this regard:
1. I thought that isEqual method is alternative to hash method,
because searching by key and searching by hash are two mutually
exclusive methods
I just made the following experiment:
I specified a hash method for my NSMapTable, but it always returns 0.
This seems to force the NSMapGet to always use key comparison for
searching for elements, as hash is always not unique.
Is this a good idea?
Let me think. The keys are quite short
On May 28, 2013, at 12:38 AM, Oleg Krupnov oleg.krup...@gmail.com wrote:
I just made the following experiment:
I specified a hash method for my NSMapTable, but it always returns 0.
This seems to force the NSMapGet to always use key comparison for
searching for elements, as hash is always
If you're going to do that, why bother with an NSMapTable at all? Just store
your pointers in a C array.
The string pointers can be different, but they can contain identical
string keys, resulting in identical values. I wanted to find values by
in a more efficient way than dumb array
On May 27, 2013, at 11:42 PM, Michael Crawford mdcrawf...@gmail.com wrote:
For purposes of looking up strings in a hash table, a 32 bit CRC
(Cyclic Redundancy Check) would be quick to calculate with few
collisions. It also doesn't require multiprecision arithmetic.
CRC is primarily a
On May 28, 2013, at 4:10 PM, Jens Alfke wrote:
CRC is primarily a checksum, not a hash function. It's good for verifying
data integrity, e.g. in a network protocol or file format, but more expensive
than you’d like for a hash table. There are much faster hash functions:
Wikipedia has a
On May 28, 2013, at 5:27 PM, Michael Hall wrote:
I thought I saw SHA-1 being used as a general purpose hash function somewhere
sort of surprising recently but I'm not remembering exactly where.
Ah, sorry to reply to my own but maybe this was it…
https://news.ycombinator.com/item?id=4036878
On 28/05/2013, at 3:46 PM, Oleg Krupnov oleg.krup...@gmail.com wrote:
I'd like to have a dictionary using C strings as keys (because I
already have const char* strings and would like to spare on creating
NSString wrappers)
For the sake of avoiding something you *assume* to be slow, or
On May 28, 2013, at 3:39 PM, Michael Hall mik3h...@gmail.com wrote:
https://news.ycombinator.com/item?id=4036878
SHA-1is still used in applications such as git as a general purpose hash
function.
Not this particular article where I saw it but I recently signed up on git
and think I may of
On May 28, 2013, at 3:39 PM, Michael Hall mik3h...@gmail.com wrote:
On May 28, 2013, at 5:27 PM, Michael Hall wrote:
I thought I saw SHA-1 being used as a general purpose hash function
somewhere sort of surprising recently but I'm not remembering exactly where.
Ah, sorry to reply to my own
Why not just create NSString wrappers? By using the
-initWithBytesNoCopy:length:encoding:freeWhenDone: method you can avoid it
copying the actual C string characters, it literally just becomes a thin
wrapper.
In my case it's more about extra calls than extra memory but thanks! Didn't
know
I'd like to have a dictionary using C strings as keys (because I
already have const char* strings and would like to spare on creating
NSString wrappers) and C structures as values.
I thought using NSMapTable would be a good idea for this.
Here is my code:
// function for comparing string keys
34 matches
Mail list logo
