Page MenuHomePhabricator

ldionne (Louis Dionne)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 11 2015, 3:26 PM (200 w, 4 h)

Recent Activity

Today

ldionne committed rCXX348994: [libcxx] Add assertion in deque::pop_back when popping from an empty deque.
[libcxx] Add assertion in deque::pop_back when popping from an empty deque
Wed, Dec 12, 4:03 PM
ldionne committed rL348994: [libcxx] Add assertion in deque::pop_back when popping from an empty deque.
[libcxx] Add assertion in deque::pop_back when popping from an empty deque
Wed, Dec 12, 4:03 PM
ldionne accepted D54814: Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`. .
Wed, Dec 12, 8:41 AM

Yesterday

ldionne committed rCXX348871: [libcxx] Only enable the availability LIT feature when we're testing libc++.
[libcxx] Only enable the availability LIT feature when we're testing libc++
Tue, Dec 11, 10:08 AM
ldionne committed rL348871: [libcxx] Only enable the availability LIT feature when we're testing libc++.
[libcxx] Only enable the availability LIT feature when we're testing libc++
Tue, Dec 11, 10:08 AM
ldionne committed rCXX348868: [libcxx] Remove the no_default_flags LIT configuration.
[libcxx] Remove the no_default_flags LIT configuration
Tue, Dec 11, 9:34 AM
ldionne committed rL348868: [libcxx] Remove the no_default_flags LIT configuration.
[libcxx] Remove the no_default_flags LIT configuration
Tue, Dec 11, 9:34 AM
ldionne committed rCXX348867: [NFC] Fix incorrect (but unreachable) LIT error message.
[NFC] Fix incorrect (but unreachable) LIT error message
Tue, Dec 11, 9:11 AM
ldionne committed rL348867: [NFC] Fix incorrect (but unreachable) LIT error message.
[NFC] Fix incorrect (but unreachable) LIT error message
Tue, Dec 11, 9:11 AM
ldionne added a comment to D55404: [libcxx] Support building static library with hidden visibility.

I'm not sure what you mean, can you elaborate on the last sentence? Without -fvisibility-global-new-delete-hidden we would end up with new and delete symbols being exported from the shared library.

Tue, Dec 11, 8:50 AM
ldionne committed rCXX348850: [libcxx] Fix test failure on GCC 4.9.
[libcxx] Fix test failure on GCC 4.9
Tue, Dec 11, 7:30 AM
ldionne committed rL348850: [libcxx] Fix test failure on GCC 4.9.
[libcxx] Fix test failure on GCC 4.9
Tue, Dec 11, 7:30 AM
ldionne committed rL348847: [pair] Mark constructors as conditionally noexcept.
[pair] Mark constructors as conditionally noexcept
Tue, Dec 11, 6:26 AM
ldionne committed rCXX348847: [pair] Mark constructors as conditionally noexcept.
[pair] Mark constructors as conditionally noexcept
Tue, Dec 11, 6:26 AM
ldionne committed rCXX348846: [libcxx] Fix test on compilers that do not support char8_t yet.
[libcxx] Fix test on compilers that do not support char8_t yet
Tue, Dec 11, 6:19 AM
ldionne committed rL348846: [libcxx] Fix test on compilers that do not support char8_t yet.
[libcxx] Fix test on compilers that do not support char8_t yet
Tue, Dec 11, 6:19 AM

Mon, Dec 10

ldionne committed rL348825: Revert "[pair] Mark constructors as conditionally noexcept".
Revert "[pair] Mark constructors as conditionally noexcept"
Mon, Dec 10, 6:36 PM
ldionne committed rCXX348825: Revert "[pair] Mark constructors as conditionally noexcept".
Revert "[pair] Mark constructors as conditionally noexcept"
Mon, Dec 10, 6:36 PM
ldionne committed rL348824: [pair] Mark constructors as conditionally noexcept.
[pair] Mark constructors as conditionally noexcept
Mon, Dec 10, 6:20 PM
ldionne committed rCXX348824: [pair] Mark constructors as conditionally noexcept.
[pair] Mark constructors as conditionally noexcept
Mon, Dec 10, 6:20 PM
ldionne closed D48669: [pair] Mark constructors as conditionally noexcept.
Mon, Dec 10, 6:20 PM
ldionne added a comment to D55532: Implement P1209 - Adopt Consistent Container Erasure from Library Fundamentals 2 for C++20.

Could you please split this change and the changes from class to struct into different patches? That would make it easier to review.

Mon, Dec 10, 4:11 PM
ldionne added a comment to D48669: [pair] Mark constructors as conditionally noexcept.

ping

Mon, Dec 10, 3:59 PM
ldionne accepted D55308: Implement the second part of P0482 (char8_t).

LGTM with the fixes to the tests.

Mon, Dec 10, 3:55 PM
ldionne added inline comments to D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch..
Mon, Dec 10, 1:30 PM
ldionne added a comment to D55517: Remove `_VSTD`.

We have two different namespaces in libc++.

We have std, which is opened by namespace std {, and referred to using std::.
We have std::__1, which is opened by _LIBCPP_BEGIN_NAMESPACE_STD, and is referred to using _VSTD.
Some things live in former, and some (most) in the latter.

They're different, and the fact that std:: will find things in std::__1 doesn't change that.

Mon, Dec 10, 12:04 PM
ldionne added a comment to D54814: Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`. .

I'd note that most of this diff was not actually required to fix the issue. E.g, in the locations where an alignment is passed to allocation/deallocation functions directly, it is perfectly fine to use the __alignof value instead of the alignof value.

We could also ameliorate some ABI breakage by continuing to use alignof within libc++, where changing to alignof would break the ABI of a standard library type. E.g., we could switch the use of std::alignment_of in any_imp to instead call __alignof, preserving behavior.

That appears to be the strategy GCC went with -- making the minimal ABI change necessary to be compliant.

Mon, Dec 10, 11:35 AM
ldionne added a comment to D55404: [libcxx] Support building static library with hidden visibility.

Ahhh, this part is what I had missed. I didn't see you were disabling the visibility annotation. In that case everything is indeed hidden. Instead, I think a cleaner approach would be:

  1. Build with hidden visibility by default at namespace scope (basically https://reviews.llvm.org/D54810), and
  2. generalize https://github.com/llvm-mirror/libcxx/blob/master/CMakeLists.txt#L742 so that we can remove visibility annotations using a CMake option.

    This way, we'd avoid adding yet another configuration option and instead leverage something we already (apparently) need and use on Windows. What do you think?

In general that sounds fine me, problem with generalizing https://github.com/llvm-mirror/libcxx/blob/master/CMakeLists.txt#L742 is that we also want to make sure that new and delete operators are hidden as well. Those operators may be implicitly declared by Clang with default visibility which defeats -fvisibility=hidden or explicit annotations which is why we've introduced -fvisibility-global-new-delete-hiddenwhich is being set in this change as well. I don't know if that's something that would affect Windows, and in general I don't know if it's something that should be enabled automatically for static libc++?

Mon, Dec 10, 11:23 AM
ldionne added inline comments to D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch..
Mon, Dec 10, 11:16 AM
ldionne added inline comments to D55308: Implement the second part of P0482 (char8_t).
Mon, Dec 10, 11:04 AM
ldionne accepted D55466: Change `tuple_size` from a `class` to a `struct` (see PR#39871).

Oh gosh I've been wondering forever why we defined them as classes in the standard. Glad to see we're fixing that.

Mon, Dec 10, 10:48 AM
ldionne accepted D55517: Remove `_VSTD`.
In D55517#1325586, @jfb wrote:

Quick Question: What's the difference between writing _VSTD:: and std::? Nothing.

I thought it was std:: _LIBCPP_ABI_NAMESPACE ?

Mon, Dec 10, 10:44 AM

Fri, Dec 7

ldionne committed rCXX348653: [libcxx] Remove the availability_markup LIT feature.
[libcxx] Remove the availability_markup LIT feature
Fri, Dec 7, 1:52 PM
ldionne committed rL348653: [libcxx] Remove the availability_markup LIT feature.
[libcxx] Remove the availability_markup LIT feature
Fri, Dec 7, 1:51 PM
ldionne added a comment to D55308: Implement the second part of P0482 (char8_t).

I would not; consider the test algorithm.version.pass.cpp, which should check for six different flags. Do you want that test to fail until libc++ implements all six of them? I do not. I want the tests to check for all the flags that libc++ has defined, and make sure that they are (a) defined, and (b) have a sane value. Things that we haven't implemented yet should not cause test failures.

Fri, Dec 7, 1:48 PM
ldionne added a comment to D55404: [libcxx] Support building static library with hidden visibility.

So... the way we planned on tackling the hidden visibility problem is https://reviews.llvm.org/D54810 (which is blocked on a couple of Clang bugs w.r.t. visibility attributes). Would https://reviews.llvm.org/D54810 solve your problem?

Also, if your intent is to make _all_ symbols hidden, I don't think this patch achieves it because we still explicitly annotate symbols in the dylib as having default visibility. Am I mistaken?

Our use case is static library while D54810 seems to focusing on shared case. Specifically, we need to link statically libc++ into various shared libraries and executables (e.g. drivers in Fuchsia) which might co-exist with other shared libraries and we need to ensure that no libc++ symbols are being exported. I suspect this might be also useful for other cases of "private libc++" such as libFuzzer.

Fri, Dec 7, 1:25 PM
ldionne accepted D55045: Add a version of std::function that includes a few optimizations..

I think I'm fine with this, but I'd still like to better understand the positive performance impact of the change. When we spoke @EricWF said he could provide an interpretation.

Fri, Dec 7, 12:10 PM
ldionne added a comment to D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch..

If you use some of my suggestions, please make sure it compiles in C++03 mode. I might be using some C++11 features (not sure whether default argument for template parameters is C++03).

Fri, Dec 7, 11:54 AM
ldionne committed rCXX348611: [libcxx] Add paranoid cast-to-void in comma operator.
[libcxx] Add paranoid cast-to-void in comma operator
Fri, Dec 7, 8:46 AM
ldionne committed rL348611: [libcxx] Add paranoid cast-to-void in comma operator.
[libcxx] Add paranoid cast-to-void in comma operator
Fri, Dec 7, 8:45 AM
ldionne requested changes to D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch..

I believe this patch fixes an important QOI bug: see http://llvm.org/PR37574. I wholeheartedly agree with Eric that allocators-over-const are an abomination, however pointers-to-const are a fine thing and our implementation should handle them gracefully.

Fri, Dec 7, 8:41 AM
ldionne requested changes to D48753: [libcxx] Use custom allocator's `construct` in C++03 when available..
  1. Just to make sure I understand; this patch has nothing to do with https://reviews.llvm.org/D48342, they are entirely orthogonal. Is this correct?
  2. Also, before this patch, the allocator's construct and destroy were NEVER called in C++03, but were called when available in C++11. After this patch, they are called when available in C++03 and in C++11. Is this correct?
Fri, Dec 7, 8:01 AM
ldionne added a comment to D55404: [libcxx] Support building static library with hidden visibility.

So... the way we planned on tackling the hidden visibility problem is https://reviews.llvm.org/D54810 (which is blocked on a couple of Clang bugs w.r.t. visibility attributes). Would https://reviews.llvm.org/D54810 solve your problem?

Fri, Dec 7, 7:22 AM

Thu, Dec 6

ldionne updated the diff for D48669: [pair] Mark constructors as conditionally noexcept.

Split libc++ specific tests into test/libcxx

Thu, Dec 6, 2:21 PM
ldionne committed rL348529: [libc++] Improve diagnostics for non-const comparators and hashers in….
[libc++] Improve diagnostics for non-const comparators and hashers in…
Thu, Dec 6, 1:49 PM
ldionne committed rCXX348529: [libc++] Improve diagnostics for non-const comparators and hashers in….
[libc++] Improve diagnostics for non-const comparators and hashers in…
Thu, Dec 6, 1:49 PM
ldionne closed D48955: [libc++] Improve diagnostics for non-const comparators and hashers in associative containers.
Thu, Dec 6, 1:49 PM
ldionne requested changes to D55308: Implement the second part of P0482 (char8_t).

Agreed.
Though I like the formulation that I posted to livcxx-dev:

#if TEST_STD_VER > 17
# if !defined(__cpp_lib_char8_t)  
  LIBCPP_STATIC_ASSERT(false, "__cpp_lib_char8_t is not defined");
# else
#  if __cpp_lib_char8_t < 201811L
#   error "__cpp_lib_char8_t has an invalid value"
#  endif
# endif
#endif

This fails silently if the macro is not defined - for libraries other than libc++.
If other library maintainers want to add (say) a libstdc++-specific assertion, then there's a place for it.

Thu, Dec 6, 1:48 PM
ldionne added a comment to D48955: [libc++] Improve diagnostics for non-const comparators and hashers in associative containers.

I'll push this as I'm fairly sure this won't affect the (already broken) build on GCC. At least not as far as I can tell.

Thu, Dec 6, 1:34 PM
ldionne committed rL348525: [libcxx] Always convert 'use_system_cxx_lib' to an absolute path.
[libcxx] Always convert 'use_system_cxx_lib' to an absolute path
Thu, Dec 6, 12:13 PM
ldionne committed rCXX348525: [libcxx] Always convert 'use_system_cxx_lib' to an absolute path.
[libcxx] Always convert 'use_system_cxx_lib' to an absolute path
Thu, Dec 6, 12:13 PM
ldionne committed rL348520: [libcxx] Fix incorrect XFAILs for chrono tests on old macos deployment targets.
[libcxx] Fix incorrect XFAILs for chrono tests on old macos deployment targets
Thu, Dec 6, 11:27 AM
ldionne committed rCXX348520: [libcxx] Fix incorrect XFAILs for chrono tests on old macos deployment targets.
[libcxx] Fix incorrect XFAILs for chrono tests on old macos deployment targets
Thu, Dec 6, 11:27 AM
ldionne committed rCXX348509: [libcxx] Add checks for unique value of array<T, 0>.begin() and array<T, 0>.end….
[libcxx] Add checks for unique value of array<T, 0>.begin() and array<T, 0>.end…
Thu, Dec 6, 10:27 AM
ldionne closed D55366: [libcxx] Add checks for unique value of array<T, 0>.begin() and array<T, 0>.end() ..

Committed as r348509.

Thu, Dec 6, 10:27 AM
ldionne committed rL348509: [libcxx] Add checks for unique value of array<T, 0>.begin() and array<T, 0>.end….
[libcxx] Add checks for unique value of array<T, 0>.begin() and array<T, 0>.end…
Thu, Dec 6, 10:27 AM
ldionne accepted D55366: [libcxx] Add checks for unique value of array<T, 0>.begin() and array<T, 0>.end() ..

Ahh, you're right. Ok, LGTM.

Thu, Dec 6, 10:14 AM
ldionne committed rL348507: [libcxx] Add XFAILs for aligned allocation tests on AppleClang 9.
[libcxx] Add XFAILs for aligned allocation tests on AppleClang 9
Thu, Dec 6, 10:10 AM
ldionne committed rCXX348507: [libcxx] Add XFAILs for aligned allocation tests on AppleClang 9.
[libcxx] Add XFAILs for aligned allocation tests on AppleClang 9
Thu, Dec 6, 10:09 AM
ldionne added a comment to D48669: [pair] Mark constructors as conditionally noexcept.

I checked both N4788 and N4788, and couldn't find any conditional noexcept on the constructors of pair.
Just explicit(see below) constexpr pair(const T1& x, const T2& y);

So I'm assuming that this is a conforming extension.
If so, I'm ok with that - but then the tests need to be libc++ specific.

Thu, Dec 6, 9:48 AM
ldionne added inline comments to D55366: [libcxx] Add checks for unique value of array<T, 0>.begin() and array<T, 0>.end() ..
Thu, Dec 6, 6:00 AM
ldionne closed D55364: [libcxx] Portability fix: make return value of array<T, 0>.data() checked only for libc++..

Committed as r348485.

Thu, Dec 6, 5:57 AM
ldionne committed rCXX348485: [libcxx] Make return value of array<T, 0>.data() checked only for libc++.
[libcxx] Make return value of array<T, 0>.data() checked only for libc++
Thu, Dec 6, 5:55 AM
ldionne committed rL348485: [libcxx] Make return value of array<T, 0>.data() checked only for libc++.
[libcxx] Make return value of array<T, 0>.data() checked only for libc++
Thu, Dec 6, 5:55 AM
ldionne accepted D55364: [libcxx] Portability fix: make return value of array<T, 0>.data() checked only for libc++..
Thu, Dec 6, 5:42 AM

Wed, Dec 5

ldionne committed rCXX348437: [libcxx] Mark some tests as failing on macosx 10.14.
[libcxx] Mark some tests as failing on macosx 10.14
Wed, Dec 5, 4:30 PM
ldionne committed rCXX348436: [libcxx] Don't depend on availability markup to provide the streams in the dylib.
[libcxx] Don't depend on availability markup to provide the streams in the dylib
Wed, Dec 5, 4:30 PM
ldionne committed rL348437: [libcxx] Mark some tests as failing on macosx 10.14.
[libcxx] Mark some tests as failing on macosx 10.14
Wed, Dec 5, 4:29 PM
ldionne committed rL348436: [libcxx] Don't depend on availability markup to provide the streams in the dylib.
[libcxx] Don't depend on availability markup to provide the streams in the dylib
Wed, Dec 5, 4:29 PM
ldionne added a comment to D48669: [pair] Mark constructors as conditionally noexcept.

ping

Wed, Dec 5, 4:21 PM
ldionne added a comment to D55308: Implement the second part of P0482 (char8_t).

Two overarching comments.

Wed, Dec 5, 1:07 PM
ldionne added inline comments to D55045: Add a version of std::function that includes a few optimizations..
Wed, Dec 5, 6:51 AM

Tue, Dec 4

ldionne updated subscribers of D53994: Fixing lower bound regression in certain situations..

@dyaroshev Can you please rebase on top of master? There's been significant changes in algorithms.bench.cpp and the patch does not apply cleanly anymore.

It seems like I need to redo my benchmarks from scratch to match what is now used. It will take me a couple of hours, so probably on the weekend.

Tue, Dec 4, 2:16 PM
ldionne added inline comments to D55045: Add a version of std::function that includes a few optimizations..
Tue, Dec 4, 11:55 AM
ldionne added a comment to D55079: [libcxx] Always enable availability in the lit test suite..

I'm going to closely monitor potential CI failures. I think only CI on Apple platforms should be affected, but I'll keep an eye out.

Tue, Dec 4, 11:35 AM
ldionne committed rCXX348296: [libcxx] Always enable availability in the lit test suite..
[libcxx] Always enable availability in the lit test suite.
Tue, Dec 4, 11:35 AM
ldionne committed rL348296: [libcxx] Always enable availability in the lit test suite..
[libcxx] Always enable availability in the lit test suite.
Tue, Dec 4, 11:34 AM
ldionne closed D55079: [libcxx] Always enable availability in the lit test suite..
Tue, Dec 4, 11:34 AM
ldionne added a comment to D53994: Fixing lower bound regression in certain situations..

@dyaroshev Can you please rebase on top of master? There's been significant changes in algorithms.bench.cpp and the patch does not apply cleanly anymore.

Tue, Dec 4, 11:29 AM
ldionne accepted D53994: Fixing lower bound regression in certain situations..

I'll apply the patch.

Tue, Dec 4, 11:06 AM
ldionne requested changes to D55045: Add a version of std::function that includes a few optimizations..

I think we need to use std::launder when accessing the function object through the small buffer. This is a problem we seem to have in the current implementation too.

Tue, Dec 4, 7:32 AM

Mon, Dec 3

ldionne added a comment to D55045: Add a version of std::function that includes a few optimizations..

Eric and I just spoke. My point of view:

Mon, Dec 3, 1:08 PM
ldionne added a comment to D55045: Add a version of std::function that includes a few optimizations..

I think this means we should only ever have at most 2 versions of std::function. One for the stable ABI and potentially an improved version for the unstable ABI.

This is where we disagree -- I don't think there's a universally better implementation of std::function. One implementation might be better in some circumstances and another implementation might be better in other circumstances, hence my claim that we should not go for a solution that assumes at most two implementations.

Our job is to provide a universal implementation of std::function, and hence pick one implementation which weights the different alternatives and chooses what we believe to be best in the majority of cases.

Mon, Dec 3, 12:04 PM
ldionne added a comment to D55045: Add a version of std::function that includes a few optimizations..

I don't see the issue with breaking ABI that's designated as unstable as long as there's some form of announcement to avoid any confusion. Fundamentally that's the entire point of having unstable ABI versions, some changes are just not really possible to make without ABI breakages, most consumers just use the stable ABI, while unstable ABI is not backwards compatible otherwise it would make a whole range of changes to libc++ and/or Clang impossible.

I don't see a problem breaking the unstable ABI either. But we don't normally standardize ABI breaking changes.

Mon, Dec 3, 11:34 AM
ldionne committed rCXX348138: [libcxx] Implement P0318: unwrap_ref_decay and unwrap_reference.
[libcxx] Implement P0318: unwrap_ref_decay and unwrap_reference
Mon, Dec 3, 6:18 AM
ldionne committed rL348138: [libcxx] Implement P0318: unwrap_ref_decay and unwrap_reference.
[libcxx] Implement P0318: unwrap_ref_decay and unwrap_reference
Mon, Dec 3, 6:06 AM
ldionne closed D54485: [libcxx] Implement P0318R1: unwrap_ref_decay and unwrap_reference.
Mon, Dec 3, 6:06 AM
ldionne added a comment to D55045: Add a version of std::function that includes a few optimizations..

FWIW, I'm slightly in favor of using different headers. For example, I just realized that this change currently leaves a bunch of baggage symbols laying around that the new code won't use, it would be easier to see that kind of thing if the internals of each function were just in it's own file.

I'm strongly against it. The harder it is to see all the implementations of a given function f, the harder it is to know they exist and keep them in sync. In my experience spreading these things out leads to real bugs.

Mon, Dec 3, 6:03 AM

Fri, Nov 30

ldionne requested changes to D55045: Add a version of std::function that includes a few optimizations..

I'd like to see benchmarking results that show the benefit of this approach.

The benchmarks are already present. We should add the results to this review to make it easier to view, but it's also possible to verify yourself.

Fri, Nov 30, 3:40 AM

Thu, Nov 29

ldionne added a comment to D55079: [libcxx] Always enable availability in the lit test suite..

@mclow.lists This should fix the test failures you've been seeing. Would you please kindly test the patch on your system? I've tested the patch under several configurations but I'd like to make sure.

Thu, Nov 29, 2:56 PM
ldionne created D55079: [libcxx] Always enable availability in the lit test suite..
Thu, Nov 29, 2:54 PM
ldionne committed rCXX347920: [libcxx] Make UNSUPPORTED for std::async test more fine grained.
[libcxx] Make UNSUPPORTED for std::async test more fine grained
Thu, Nov 29, 1:28 PM
ldionne committed rL347920: [libcxx] Make UNSUPPORTED for std::async test more fine grained.
[libcxx] Make UNSUPPORTED for std::async test more fine grained
Thu, Nov 29, 1:28 PM
ldionne committed rCXXA347903: [libcxx] Remove bad_array_length.
[libcxx] Remove bad_array_length
Thu, Nov 29, 11:49 AM
ldionne committed rL347903: [libcxx] Remove bad_array_length.
[libcxx] Remove bad_array_length
Thu, Nov 29, 11:48 AM
ldionne committed rCXX347903: [libcxx] Remove bad_array_length.
[libcxx] Remove bad_array_length
Thu, Nov 29, 11:48 AM
ldionne closed D54804: [libcxx] Remove bad_array_length.
Thu, Nov 29, 11:47 AM
ldionne added a comment to D54804: [libcxx] Remove bad_array_length.

I'd like to merge this early in the cycle to give vendors the chance to notice failures in case there are any (but we don't expect that to happen given our investigation). I'll merge this now because I'm not aware of any other vendor that could be worried by this (and so the waiting time implied by Duncan's question above is potentially unbounded). However, if anyone has concerns, please comment here and I'll insta-revert until we've come to an agreement.

Thu, Nov 29, 11:45 AM
ldionne updated the diff for D54804: [libcxx] Remove bad_array_length.

Added release notes.

Thu, Nov 29, 11:41 AM
ldionne requested changes to D55045: Add a version of std::function that includes a few optimizations..

I'd like to see benchmarking results that show the benefit of this approach.

Thu, Nov 29, 9:03 AM