in reply to Re^4: RFC - Tie::Hash::Ranked
in thread RFC - Tie::Hash::Ranked

I agree that tie is inefficient. But it is a constant factor overhead - your code is slower but still scales reasonably. I draw a big distinction between that and algorithmic inefficiency which can cause code to fall over surprisingly fast.

As for the API, pass me the information any way you want. All of the options that you mention are supported if I get the following information: 

my $cmp = sub {
  my ($key_a, $value_a, $key_b, $value_b) = @_;
  # do some comparison
};

[download]

Replies are listed 'Best First'.
Re^6: RFC - Tie::Hash::Ranked
by stvn (Monsignor) on Oct 12, 2004 at 17:26 UTC
    I draw a big distinction between that and algorithmic inefficiency which can cause code to fall over surprisingly fast.

    Not that I doubt you, but could you please be more specific as to why you think this code will "fall over surprisingly fast". I mean, maybe you are correct, but I would think one would need to really analyze the code, and runs some tests/benchmarks before making such a strong declaration.

    As for the API, pass me the information any way you want. All of the options that you mention are supported if I get the following information:

    I will only just say that this contradicts the efficiency argument, since it requires you to do two (possibly unnessecary) hash lookups for each loop of the sort.

    To be honest, I am not really looking to argue with you about this, but only to point out that your comment , which was very short, made some assumptions which while not wholly wrong, were not really all that right either and certainly were not founded upon use or study of the module in question. You being a high level saint, and a long standing member of this community means that many people listen to and place value on what you say. To make quick, ambigious and somewhat disparaging comments about a module you have never used and never plan to use is (IMO) not really useful to the discussion.

    -stvn
[reply]
      More specific? Sure.

      It's all in the big O. Suppose that your code runs OK when you have 1000 data points, how long do you expect it to take when it processes a sample of 50,000 data points? 50 times as long, or 2500 times as long? The latter can cause very nasty surprises. For an extreme example, if this code is being used somewhere that you have constant requests coming in (eg a website), as soon as the time to respond goes over the time between requests, your system will fall over. Been there, done that, not fun.

      Therefore I'm careless of micro-optimizations until there is a proven problem, but I tend to stay much more aware of algorithmic efficiency issues.

      As for whether it is useful to make quick comments about a module, what I'm really trying to communicate is that this is how I evaluate unknown modules. I sanity check them, and if there a significant red flag comes up, I won't use them in serious work. I do this because I think that it is a good practice. Because I think that it is a good practice, I think that there is value in encouraging other people to think about how they handle this. Certainly much more value than the common refrain of saying, It's on CPAN, use it!

[reply]

        Excellent points, all of them. Thanks for clarifying.

        Because I think that it is a good practice, I think that there is value in encouraging other people to think about how they handle this.

        Personally, I only look if I have a need, then when I find something that looks promising (I like the API, the docs make sense) I look around the net to see what (if anything) other people have to say. Which is why I wanted you to clarify your remarks, for future monks to be able to see in details your reasoning ;-)

        -stvn
[reply]

In Section Meditations