On 31 May 2013, at 01:43, Jens Alfke wrote:
>
> On May 30, 2013, at 3:52 AM, Ian Joyner 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
On 5/30/13, Jens Alfke wrote:
>
> On May 29, 2013, at 11:35 PM, Eric Wing 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
On May 30, 2013, at 3:52 AM, Ian Joyner 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
> we should wri
On May 29, 2013, at 11:35 PM, Eric Wing 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.
If you’re codi
On May 30, 2013, at 3:52 AM, Ian Joyner 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
> we should wri
On 30 May 2013, at 12:33, Jens Alfke wrote:
>
> On May 29, 2013, at 6:30 PM, Ian Joyner 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,
Le 30 mai 2013 à 08:35, Eric Wing a écrit :
> On 5/29/13, Jens Alfke wrote:
>>
>> On May 29, 2013, at 8:29 PM, Eric Wing 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
On 5/29/13, Jens Alfke wrote:
>
> On May 29, 2013, at 8:29 PM, Eric Wing 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
>> pe
On 5/29/13, Charles Srstka wrote:
> On May 29, 2013, at 10:29 PM, Eric Wing 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
On May 29, 2013, at 8:29 PM, Eric Wing 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 unfair to include
On May 29, 2013, at 10:29 PM, Eric Wing 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 appear periodically
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 foun
On May 29, 2013, at 6:30 PM, Ian Joyner 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 optimization is the
On 29 May 2013, at 14:14, Oleg Krupnov 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 running subroutine cal
On May 28, 2013, at 9:14 PM, Oleg Krupnov 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 optimization is evil,
On May 28, 2013, at 9:14 PM, Oleg Krupnov 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, also: What you’ve said
Le 29 mai 2013 à 06:14, Oleg Krupnov 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 case it's more
Le 29 mai 2013 à 00:46, Graham Cox a écrit :
>
> On 28/05/2013, at 3:46 PM, Oleg Krupnov 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
On May 28, 2013, at 5:55 PM, Greg Parker wrote:
> On May 28, 2013, at 3:39 PM, Michael Hall 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
> 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
k
On May 28, 2013, at 3:39 PM, Michael Hall 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 but maybe th
On May 28, 2013, at 3:39 PM, Michael Hall 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 seen it's use
On 28/05/2013, at 3:46 PM, Oleg Krupnov 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 inefficient,
you've take
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 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 27, 2013, at 11:42 PM, Michael Crawford 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 checksum, not a hash fun
> 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 iteratio
On May 28, 2013, at 12:38 AM, Oleg Krupnov 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 "not unique".
>
> I
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 string
Le 28 mai 2013 à 08:25, Oleg Krupnov 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 of looking up
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 calcul
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
On May 27, 2013, at 10:46 PM, Oleg Krupnov 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 previous records are perfe
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
st
34 matches
Mail list logo
