This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Optimize _BFSExecutor in regex
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Tim Shen <timshen91 at gmail dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 8 Oct 2013 01:43:07 +0100
- Subject: Re: [Patch] Optimize _BFSExecutor in regex
- Authentication-results: sourceware.org; auth=none
- References: <CAPrifDkH0sC3FwfUrWC4Nb3h6GYsCUTvdmrgf_+UN1ZfmJwrsw at mail dot gmail dot com> <CAH6eHdQjKNAzLXCoA07T7tB5HfExEFN8rCBayvP=GCS1_=BiPg at mail dot gmail dot com> <CAPrifDko9SnheJ+aQ45W5NLyK5NKHfP_-3f0pczROiXCKf8bDg at mail dot gmail dot com> <CAH6eHdS0B6wpXQdhXTbXo1PgjnuUSjfoAbK404VE+MPAya48FQ at mail dot gmail dot com> <CAPrifDk6R9wtoZNewyNpESgkx1J6YW0xJNaut0tG-ta5RJ3p+w at mail dot gmail dot com> <CAH6eHdS81ftVScJW_zhxt=gW=2g60fnHA=0O70AQr0jpB-m4ug at mail dot gmail dot com> <CAPrifDndETV=aU82C9BB0rZv=VQRwU36WxWzM09raHEoQ8gXHA at mail dot gmail dot com> <CAH6eHdQv-fyiz2mSzOgh5EhokSKxRrbUuVvFe161Wt2+3_BNvQ at mail dot gmail dot com> <CAPrifD=VVgG9oicJR-fAALJs_sp7MfNU8JcA83VciKpb35PpVA at mail dot gmail dot com> <CAH6eHdSAH+u9gfboO9+EM1QqCdKi2rXi+7fATjF0ecYS9iJUJw at mail dot gmail dot com> <CAPrifDmDjx=F9gr6WUice1rrOEiShxFGtLBB2v4CASJpe-L4vQ at mail dot gmail dot com>
On 8 October 2013 01:06, Tim Shen wrote:
> On Mon, Oct 7, 2013 at 7:11 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> The version in your gist (which is *not* what your first patch did!)
>> is faster for any size of _M_exists and any ratio of _M_states.size()
>> / _M_exists.size():
>
> Sorry for my original patch, I made a mistake! It's:
> while (!_BaseT::empty())
> _BaseT::pop_back();
> but I truely meant:
> while (!this->_M_empty())
> this->_M_pop();
> To make all trues reset.
Yes, that's what I was trying to say in my first mail :-)
> In my machine the while loop is slower than assign() when the
> _M_states.size() / _M_exists.size() is more than even 7/1000. so let's
> keep the assign(), because the ratio in regex could probably be more
> than 25%.
OK, this latest patch looks good so please go ahead and commit it - thanks!