On 17 January 2014 10:33, Tim Shen wrote:
> I agree, especially after I finding that an exported symbol could only
> be removed in a main version changing.
Maybe never!
> Anyway, we'll win some run-time
> cases, on which, we beat Boost ;)
That's excellent, well done :-)
On Fri, Jan 17, 2014 at 4:39 AM, Jonathan Wakely wrote:
> On 8 January 2014 22:47, Tim Shen wrote:
> I think we want to be cautious with exporting instantiations (and as
> Paolo noted we definitely don't want to do it for 4.9.0 now). Slow
> compile times are a problem, but only a minor annoyance.
On 8 January 2014 22:47, Tim Shen wrote:
>
> So my plan is to instantiate _Compiler and _Executor instead of user
> interfaces like basic_regex or regex_match, because the implementation
> may change (say add a new executor) later. Is that Ok?
I think we want to be cautious with exporting instanti
On 9 January 2014 10:13, Paolo Carlini wrote:
> On 01/08/2014 11:47 PM, Tim Shen wrote:
>>
>> On Wed, Jan 8, 2014 at 5:38 PM, Paolo Carlini
>> wrote:
>>>
>>> I agree, it's probably fine for now, but please actually attach the patch
>>> ;)
>>
>> Oops sorry >.<
>
> Jon, is this version Ok with you?
On Thu, Jan 9, 2014 at 5:13 AM, Paolo Carlini wrote:
> On 01/08/2014 11:47 PM, Tim Shen wrote:
>>
>> On Wed, Jan 8, 2014 at 5:38 PM, Paolo Carlini
>> wrote:
>>>
>>> I agree, it's probably fine for now, but please actually attach the patch
>>> ;)
>>
>> Oops sorry >.<
>
> Jon, is this version Ok wi
On 01/08/2014 11:47 PM, Tim Shen wrote:
On Wed, Jan 8, 2014 at 5:38 PM, Paolo Carlini wrote:
I agree, it's probably fine for now, but please actually attach the patch ;)
Oops sorry >.<
Jon, is this version Ok with you?
Thanks,
Paolo.
On Wed, Jan 8, 2014 at 5:38 PM, Paolo Carlini wrote:
> I agree, it's probably fine for now, but please actually attach the patch ;)
Oops sorry >.<
So my plan is to instantiate _Compiler and _Executor instead of user
interfaces like basic_regex or regex_match, because the implementation
may chan
Hi,
On 01/08/2014 11:11 PM, Tim Shen wrote:
On Wed, Jan 8, 2014 at 5:20 AM, Paolo Carlini wrote:
On 01/08/2014 10:24 AM, Jonathan Wakely wrote:
Ouch! Yes, that's quite a bit slower, and this code is already very
slow to compile.
With this patch (who is based on a-fixed.diff, committed earler
On Wed, Jan 8, 2014 at 5:20 AM, Paolo Carlini wrote:
> On 01/08/2014 10:24 AM, Jonathan Wakely wrote:
>> Ouch! Yes, that's quite a bit slower, and this code is already very
>> slow to compile.
With this patch (who is based on a-fixed.diff, committed earlerly),
who use templated member functions i
On 01/07/2014 08:36 PM, Tim Shen wrote:
On Tue, Jan 7, 2014 at 4:02 AM, Paolo Carlini wrote:
Ideally, I would suggest committing first the improvements in your previous
patch (by the way, thanks for the numbers!) + the pure bug fixes and
separate the further performance improvements which have
Hi,
On 01/08/2014 10:24 AM, Jonathan Wakely wrote:
On 7 January 2014 19:36, Tim Shen wrote:
I didn't noticed that's so time consuming. I think reducing the
compile time is possible (by templating several member functions
instead of whole _Compiler<> class).
Ouch! Yes, that's quite a bit slower
On 7 January 2014 19:36, Tim Shen wrote:
>
> I didn't noticed that's so time consuming. I think reducing the
> compile time is possible (by templating several member functions
> instead of whole _Compiler<> class).
Ouch! Yes, that's quite a bit slower, and this code is already very
slow to compile
On Tue, Jan 7, 2014 at 4:02 AM, Paolo Carlini wrote:
> Ideally, I would suggest committing first the improvements in your previous
> patch (by the way, thanks for the numbers!) + the pure bug fixes and
> separate the further performance improvements which have compile-time
> performance implicatio
Hi,
On 01/07/2014 07:48 AM, Tim Shen wrote:
I'd prefer to propose another patch that should be commited with this
one, which fix bugs (say _M_flags & regex_constants::icase, not "&&"),
and do more "matcher optimization".
It is now more DRY (_RegexTranslator<>) and efficient, but
takes longer
I'd prefer to propose another patch that should be commited with this
one, which fix bugs (say _M_flags & regex_constants::icase, not "&&"),
and do more "matcher optimization".
It is now more DRY (_RegexTranslator<>) and efficient, but
takes longer to compile, mainly because now we have 4 times
On Fri, Jan 3, 2014 at 9:35 PM, Tim Shen wrote:
> The data structure _BracketMatcher (storing regex like [123a-z]) could
> be quite slow mainly because of regex_traits. So a result of cache for
> small range of inputs (char) sounds reasonable. It iterates all 256
> inputs and calculate them at reg
On Sat, Jan 4, 2014 at 4:25 AM, Paolo Carlini wrote:
> Good. Could we actually measure something in the performance testsuite?
Before:
split.cc 108r 107u
0s0mem0pf
split_bfs.cc 192r 191
Hi,
On 01/04/2014 03:35 AM, Tim Shen wrote:
The data structure _BracketMatcher (storing regex like [123a-z]) could
be quite slow mainly because of regex_traits. So a result of cache for
small range of inputs (char) sounds reasonable. It iterates all 256
inputs and calculate them at regex compile
The data structure _BracketMatcher (storing regex like [123a-z]) could
be quite slow mainly because of regex_traits. So a result of cache for
small range of inputs (char) sounds reasonable. It iterates all 256
inputs and calculate them at regex compile time.
Booted and tested under -m64 and -m32.
19 matches
Mail list logo
