First, my email client died, so I don't know if my original response went out. I apologize if there is a duplicate here:
Thanks for the info on get_slice -- it's serving me well now. However, your response definitely rubbed me the wrong way. Exceptions are a special feature of languages often with their own keywords, primitives, and usually chapters in books. I don't profess to be an expert in the various exception models for all the versions of various implementations of C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml that thrift supports. But I would claim that, with such a large heterogeneous and dynamic support base, one should use something as varied and unpredictable as the exception handling models with great care and I don't "personally feel" that the understandably expected error case of Get should be escalated to be handled by this mechanism. I'm curious as to what others think about this - I realize that handling this case is more philosophy driven then anything. Thanks... -----Original Message----- From: Jonathan Ellis [mailto:[email protected]] Sent: Tue 10/27/2009 11:35 AM To: [email protected] Subject: Re: Performance of get On Tue, Oct 27, 2009 at 12:20 PM, Christopher McKenzie <[email protected]> wrote: > Checking for existence, a normal control flow operation, requires using a > try/catch method, which are not intended for normal control flow. That was conventional wisdom in the '80s. Less so today. (Along with gems like "there should only be one return point from any function." Remember that one?) > My experience with PHP has shown that interrupts come at a cost of about 200 > times that of a type check. > Could Get possibly return a reserved value instead? Sorry, it's not worth breaking everyone's existing code to accommodate the PHP vm sucking. Have you actually tested to make sure it's not fast "enough?" I'm really skeptical that even with a terrible exception design, this will be the bottleneck compared with network + cassandra latency + the rest of your code. If it really is your bottleneck, you have a couple options: - use get_slice, which will return an empty list instead of throwing NFE [the thrift interface declares that it throws, but this is wrong, I will fix it] - use python; we just did some testing with a miss-dominated workload and the client was not a bottleneck even at 20000+ req/s -Jonathan
<<winmail.dat>>
