FAQ

On 2013/12/19 16:33:40, rsc wrote:
On Thu, Dec 19, 2013 at 2:29 AM, wrote:

Wait, can this pool be made global now?
No. The machine is sized according to the regexp it can execute.
I see.

I guess it does not make sense to have a global array of Pools for
different "size classes".

The remaining concern is:
Are there cases where a program creates lots of local short-lived
regexps (one-shot), and it's not possible to replace them with global
ones? For this case we've introduced a global contended mutex.


https://codereview.appspot.com/44150043/

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Russ Cox at Jan 6, 2014 at 6:38 pm

    On Fri, Dec 20, 2013 at 1:18 AM, wrote:

    On 2013/12/19 16:33:40, rsc wrote:
    On Thu, Dec 19, 2013 at 2:29 AM, wrote:
    Wait, can this pool be made global now?
    No. The machine is sized according to the regexp it can execute.
    I see.

    I guess it does not make sense to have a global array of Pools for
    different "size classes".

    The remaining concern is:
    Are there cases where a program creates lots of local short-lived
    regexps (one-shot), and it's not possible to replace them with global
    ones? For this case we've introduced a global contended mutex.
    Yes, that happens in any case where a program computes the regexp at run
    time. That's a bit unfortunate. Maybe this should be rolled back.

    Brad, was there any performance improvement here?

    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Jan 6, 2014 at 6:45 pm

    On Mon, Jan 6, 2014 at 10:38 PM, Russ Cox wrote:
    On Fri, Dec 20, 2013 at 1:18 AM, wrote:
    On 2013/12/19 16:33:40, rsc wrote:

    On Thu, Dec 19, 2013 at 2:29 AM, wrote:
    Wait, can this pool be made global now?
    No. The machine is sized according to the regexp it can execute.

    I see.

    I guess it does not make sense to have a global array of Pools for
    different "size classes".

    The remaining concern is:
    Are there cases where a program creates lots of local short-lived
    regexps (one-shot), and it's not possible to replace them with global
    ones? For this case we've introduced a global contended mutex.

    Yes, that happens in any case where a program computes the regexp at run
    time. That's a bit unfortunate. Maybe this should be rolled back.

    Brad, was there any performance improvement here?

    We can have best of both worlds -- one element local pool + sync.Pool.
    If we ever put second element into the local pool (which never happens
    for local regexp's), then switch to sync.Pool.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brad Fitzpatrick at Jan 6, 2014 at 6:49 pm

    On Mon, Jan 6, 2014 at 10:38 AM, Russ Cox wrote:
    On Fri, Dec 20, 2013 at 1:18 AM, wrote:

    On 2013/12/19 16:33:40, rsc wrote:
    On Thu, Dec 19, 2013 at 2:29 AM, wrote:
    Wait, can this pool be made global now?
    No. The machine is sized according to the regexp it can execute.
    I see.

    I guess it does not make sense to have a global array of Pools for
    different "size classes".

    The remaining concern is:
    Are there cases where a program creates lots of local short-lived
    regexps (one-shot), and it's not possible to replace them with global
    ones? For this case we've introduced a global contended mutex.
    Yes, that happens in any case where a program computes the regexp at run
    time. That's a bit unfortunate. Maybe this should be rolled back.

    Brad, was there any performance improvement here?
    I didn't measure. I was going for code cleanliness and finding places where
    it should in theory be best, assuming a good implementation of sync.Pool.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Jan 6, 2014 at 8:34 pm
    Let's just roll back this CL and end this discussion until there is an
    important performance case to analyze.

    Thanks.
    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brad Fitzpatrick at Jan 6, 2014 at 8:34 pm
    sure


    On Mon, Jan 6, 2014 at 12:34 PM, Russ Cox wrote:

    Let's just roll back this CL and end this discussion until there is an
    important performance case to analyze.

    Thanks.
    Russ
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedDec 20, '13 at 6:18a
activeJan 6, '14 at 8:34p
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase