On Wed, May 4, 2016 at 3:46 PM, Peter Saint-Andre <[email protected]> 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 -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
