[bind10-dev] whether/when to use exceptions

[JINMEI Tatuya / 神明達哉]

At Fri, 9 Oct 2009 00:32:03 -0400,
christos at zoulas.com (Christos Zoulas) wrote:

> | Whether or not we use our own exceptions heavily, we should also note
> | that it's (very) difficult to make the code completely exception-free,
> | especially if we want to use STL (and I think we do) because we should
> | also expect a std::bad_alloc exception.  So, I suspect we'll need to
> | have some try-catch anyway.
> 
> It depends what are your goals. The STL code is very uneven; some of it
> is pretty good, but there are parts that are really bad (the hashtable
> is a red-black tree internally, and the default string hashing function
> is poor for example). It also does excessive allocations and de-allocations.
> 
> Strings are not great either... If you want a high performance application,
> you'll probably want to avoid STL. If you don't care about burning CPU,
> STL is fine.
> 
> The latest example was one someone @ work wrote a feed handler using STL
> that used ~60% cpu, and when we ripped out all the STL code and used plain
> c stuff, it used < 10%... Again this was an application where STL did
> excessive allocation/deallocation and this really hurt performance.

Hmm...if we really decide to eliminate both exceptions (completely)
and STL, I guess we'd lose much of the original motivation of (my
understanding of) why we chose C++ in the first place.

As for the efficiency concern about STL, I see it.  I've not fully
considered the performance implication in my initial experimental
work, but I was still aware of it.  My initial considerations on this
point are:

- performance doesn't matter much for the DNS name/RR/message API as a
  general purpose library.  I guess most of the users will be happy
  with a moderate level of performance (e.g., they wouldn't have to
  handle 100,000qps), and clarity and convenience would be more
  important.  I believe STL helps here.

- for performance-sensitive applications such as
  authoritative/recursive DNS servers that would be included in the
  base BIND10 package, we'll still use the same interface but
  implement it in a more efficient way internally.  For example, while
  the user of the general API may use the generic "Name" class, which
  may internally uses std::string, the internal server version would
  represent a DNS name as a bare char * string which is located
  somewhere in the on-memory database.  Also, we could probably avoid 
  allocation/deallocation overhead with STL (in some limited optimized
  cases) by pre-reserving a reasonably sufficient space and reusing the
  same STL container as much as possible (and storing pointer or
  pointer-like objects in the container, rather than a copy of a real
  object)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.