Re: [sip-ops] [dispatch] SIP-CLF: Results on ASCII vs. binary representation

Theo Zourzouvillys <theo@crazygreek.co.uk> Wed, 29 April 2009 19:03 UTC

Return-Path: <theo@crazygreek.co.uk>
X-Original-To: sip-ops@core3.amsl.com
Delivered-To: sip-ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E9A3A6D40; Wed, 29 Apr 2009 12:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.847
X-Spam-Level:
X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDfn79ji7Vps; Wed, 29 Apr 2009 12:03:17 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with SMTP id 3C3CA28C2AA; Wed, 29 Apr 2009 12:02:01 -0700 (PDT)
Received: from source ([209.85.218.224]) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSfike3mFeRqeWlX8Ps4oatnjVByy9iKl@postini.com; Wed, 29 Apr 2009 12:03:24 PDT
Received: by bwz24 with SMTP id 24so1387084bwz.22 for <multiple recipients>; Wed, 29 Apr 2009 12:03:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.64.67 with SMTP id d3mr594033bki.142.1241031802132; Wed, 29 Apr 2009 12:03:22 -0700 (PDT)
In-Reply-To: <49F8988C.9050900@alcatel-lucent.com>
References: <49F864E8.20005@alcatel-lucent.com> <167dfb9b0904290847u322161d5h3da18771344436ec@mail.gmail.com> <49F8988C.9050900@alcatel-lucent.com>
From: Theo Zourzouvillys <theo@crazygreek.co.uk>
Date: Wed, 29 Apr 2009 20:03:02 +0100
Message-ID: <167dfb9b0904291203m4e74ab39s5f83cfa1be9799a0@mail.gmail.com>
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: sip-ops@ietf.org, dispatch@ietf.org, sipping WG <sipping@ietf.org>
Subject: Re: [sip-ops] [dispatch] SIP-CLF: Results on ASCII vs. binary representation
X-BeenThere: sip-ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Operations <sip-ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-ops>, <mailto:sip-ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-ops>
List-Post: <mailto:sip-ops@ietf.org>
List-Help: <mailto:sip-ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-ops>, <mailto:sip-ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2009 19:03:18 -0000

On Wed, Apr 29, 2009 at 7:12 PM, Vijay K. Gurbani
<vkg@alcatel-lucent.com> wrote:

> 1) On some systems, the value of IOV_MAX is set to a low number.

(1) is irrelivant.  scatther/gather is not the only optimal method of
implementing it.  even on crappy old OSes, a simple memcpy() of the
data is similar in performance, cache coherency caveat emptor:

  http://dev.voip.co.uk/~theo/write-clf.theo2.txt

Binary: 0m7.400s
ASCII: 0m7.038s

> (1) is a real concern because as you can well imagine that URIs,
> once parsed, can be composed of many different objects (or
> structs in C.)  As such, the representation of a composed URI
> in a iov structure will require multiple indexes.

i'd argue your concerns are moot - a URI composed of many different
objects will need to be built into a string if it's ASCII anyway.

to be honest, i through they took the performance card out of the pack
so it couldn't be used any more in 2002 - if logging is causing you
scalability problems, you've got far more to worry about than that.
plus, any implementation not running on a modern OS is going to have
other missing features needed for performance improvements outside of
writev()'s limitations

(ps: i'm not too concerned about binary/ascii - although i lean toward
the binary side - please just don't use performance as an argument
unless the figures are fair. pretty please!)

 ~ Theo

-- 
http://twitter.com/zourzouvillys
http://crazygreek.co.uk/