Re: [precis] order of operations (was: Re: Milestones changed for precis WG)

Sam Whited <> Wed, 04 May 2016 22:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F12C12D655 for <>; Wed, 4 May 2016 15:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VG9e-Zbx1Uoo for <>; Wed, 4 May 2016 15:27:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9084E12D923 for <>; Wed, 4 May 2016 15:27:28 -0700 (PDT)
Received: by with SMTP id x7so34179612qkd.3 for <>; Wed, 04 May 2016 15:27:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=manMWK7vaKyJtOpnvcAhqKXJOCjlg3YHnNLXkFNLx5o=; b=hjO/V0OtZO/Jzj97nKGLBHxOdp8xcM1omaYzvSJBsJb1wjLtcyev2Z18y+1ZmSVVxd Pyio3qMXfw1FHNuEfS8YTUwB14XYZ3klhUlxzjRBWlfVtZ3gHslbj7r91iXFFuwG0phk /fxbJZDHP1bsEl4rCNAd9ac9PiIH6wlANuE4Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=manMWK7vaKyJtOpnvcAhqKXJOCjlg3YHnNLXkFNLx5o=; b=UZXkOqt1IzPFEjEOcnqDsz9XgGLIJA7GEJtJqk6/v6ckMDDlOLutVO3HRocWaM0TAx /LhqnjskcN/Tts7dcg5kw/B10QJ38UiwDG1n7T0lULUIaF1uY+hQe/fGhPStb8lH9zJ1 XeCHHbMWjEXfrnsFwkZFldriFXp8R6H4DieU3CjYbmuXaw4lUiQHBKISizeyHRTMh5Vp 5BR3Zpa2Je2YU/e3290nHTqEHZoXCOw4G2J1JabtiG2AF2YjrXSSzQ1+KGfTFaPce53Q blaJaZ4FRuUFdNItPgscwMljTy0/RTa6Hzlu7rIIdUpaYH5G+kEUx31POZ6tYjgTW91c YiDg==
X-Gm-Message-State: AOPr4FUl7C4qqAG9n4QouBA1pE2LWCuOTny15QPFH5LWplXKgDSlvgfbVOzaPrTd/sZN40gs3IjLphI2AadUZQ==
X-Received: by with SMTP id 36mr11840359qkx.149.1462400847195; Wed, 04 May 2016 15:27:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 4 May 2016 15:26:47 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Sam Whited <>
Date: Wed, 4 May 2016 17:26:47 -0500
Message-ID: <>
To: Peter Saint-Andre <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [precis] order of operations (was: Re: Milestones changed for precis WG)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 May 2016 22:27:30 -0000

On Wed, May 4, 2016 at 3:46 PM, Peter Saint-Andre <> wrote:
> There's also the question of whether preparation / pre-processing is all
> that useful. We added it so that constrained clients (e.g., clients that
> can't realistically perform normalization) could avoid most of the problems
> associated with having their strings rejected by a more powerful server that
> actually does enforcement and comparison. Whether we really need to consider
> such applications is another story.

I'd be curious to know a "real world" use case for the preparation
step optimization where enforcement is prohibitively expensive and
comparison is not necessary (since comparison necessitates
enforcement)? While benchmarking the implementation I did for Go I
decided that it wasn't necessary to include a preparation step. Even
on a heavily resource constrained server the enforcement step was easy
to run concurrently or in parallel, and was very fast, even in its
unoptimized form (most of the time spent in the algorithm was on
memory allocation, which could easily be reduced). You can't count on
concurrency or parallelism in all systems of course, but since it also
wasn't all that time complex my suspicion is that the preparation step
is premature optimization even on synchronous systems (although I
haven't actually tested this).


Sam Whited
pub 4096R/54083AE104EA7AD3