[issue14478] Decimal hashing very slow, could be cached

Mark Dickinson added the comment: Closing as fixed (for the C version, at least). -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue14478] Decimal hashing very slow, could be cached

Changes by Mark Dickinson : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14478] Decimal hashing very slow, could be cached

Mark Dickinson added the comment: I agree with Raymond: I don't see a real need to patch the Python version here. If we do want to patch the Python version, I'd go with Raymond's simple patch. -- ___ Python tracker

[issue14478] Decimal hashing very slow, could be cached

Changes by Antoine Pitrou : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue14478] Decimal hashing very slow, could be cached

Serhiy Storchaka added the comment: The C version of decimal may not always be available. In particular, it is not compatible with C89. Therefore, efficiency of the pure Python version of decimal is important. Any chance to get it in Python 3.3? -- __

[issue14478] Decimal hashing very slow, could be cached

Raymond Hettinger added the comment: I don't see a need to cache the hash value in the pure Python version. -- ___ Python tracker ___ ___

[issue14478] Decimal hashing very slow, could be cached

Serhiy Storchaka added the comment: > Using except: pass as opposed to sticking everything inside the except > statement is also very slightly slower as well I ran the test several times and didn't see the difference between pass and sticking variants more than between different runs of the sa

[issue14478] Decimal hashing very slow, could be cached

Amaury Forgeot d'Arc added the comment: > Checking for the AttributeError is very slightly slower Why are you trying to micro-optimize the Python version, when the C implementation does it better and faster? -- nosy: +amaury.forgeotdarc ___ Python t

[issue14478] Decimal hashing very slow, could be cached

Serhiy Storchaka added the comment: > I can't imagine any other exception coming from that try statement. KeyboardInterrupt -- ___ Python tracker ___ __

[issue14478] Decimal hashing very slow, could be cached

James Hutchison added the comment: In the patch: This: +except AttributeError: +pass should be: +except: Checking for the AttributeError is very slightly slower. Not by a lot, but I think if we're going for speed we might as well be as fast as possible. I can't

[issue14478] Decimal hashing very slow, could be cached

Serhiy Storchaka added the comment: > The patch for the Python version looks good to me Oh, but used by James Hutchison approach is faster. When I disable the _decimal: Unpatched: int: 2.24056077003479 CachingDecimal: 8.49468207359314 Decimal: 187.68132972717285 With rhettinger's LBYL patc

[issue14478] Decimal hashing very slow, could be cached

Stefan Krah added the comment: The patch for the Python version looks good to me. -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue14478] Decimal hashing very slow, could be cached

Stefan Krah added the comment: I changed the C version to cache the hash as well: For the submitted test case the speedup is only 5x, but hashing times vary greatly depending of the size of the coefficient and the exponent. BTW, the tests already call both hash() and __hash__() on the same num

[issue14478] Decimal hashing very slow, could be cached

Roundup Robot added the comment: New changeset a012d5df2c73 by Stefan Krah in branch 'default': Issue #14478: Cache the hash of a Decimal in the C version. http://hg.python.org/cpython/rev/a012d5df2c73 -- nosy: +python-dev ___ Python tracker

[issue14478] Decimal hashing very slow, could be cached

Jim Jewett added the comment: Stefan Krah has a good point. Since the only cost is an extra slot, and this is for users who have already chosen to use Decimal instead of a more efficient (but possibly less accurate) representation, even without the native speedups to Decimal ... I guess I'm

[issue14478] Decimal hashing very slow, could be cached

Stefan Krah added the comment: I think it would be a good idea to fix this in the Python version for the other implementations. -- ___ Python tracker ___ ___

[issue14478] Decimal hashing very slow, could be cached

Antoine Pitrou added the comment: Le samedi 07 avril 2012 à 17:22 +, Raymond Hettinger a écrit : > -- > keywords: +patch > Added file: http://bugs.python.org/file25152/decimal_hash.diff I think patching the C version of Decimal would be more useful :) -- __

[issue14478] Decimal hashing very slow, could be cached

Changes by Raymond Hettinger : -- keywords: +patch Added file: http://bugs.python.org/file25152/decimal_hash.diff ___ Python tracker ___ _

[issue14478] Decimal hashing very slow, could be cached

Antoine Pitrou added the comment: > > > I recommend that __hash__ should use functools.lru_cache for caching. > > Why would you do such a thing? A hash value is a single 64-bit slot, no > > need to add the memory consumption of a whole dictionary and the runtime > > cost of a LRU eviction poli

[issue14478] Decimal hashing very slow, could be cached

Serhiy Storchaka added the comment: > > I recommend that __hash__ should use functools.lru_cache for caching. > Why would you do such a thing? A hash value is a single 64-bit slot, no need > to add the memory consumption of a whole dictionary and the runtime cost of a > LRU eviction policy whe

[issue14478] Decimal hashing very slow, could be cached

Changes by Antoine Pitrou : -- stage: -> needs patch versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list ma

[issue14478] Decimal hashing very slow, could be cached

Antoine Pitrou added the comment: > I recommend that __hash__ should use functools.lru_cache for caching. Why would you do such a thing? A hash value is a single 64-bit slot, no need to add the memory consumption of a whole dictionary and the runtime cost of a LRU eviction policy when you can

[issue14478] Decimal hashing very slow, could be cached

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue14478] Decimal hashing very slow, could be cached

Jim Jewett added the comment: @Jimbofbx: You are correct that a value has to be reserved to indicate that the hash hasn't been (or can't be) computed, but python uses -1 instead of zero. An integer can't return itself because a hash is an unboxed integer; that said, there is a fast path for

[issue14478] Decimal hashing very slow, could be cached

James Hutchison added the comment: I presume you mean in 3.2? Have you looked at the source code for that decorator? It's fundamentally a try/except but with a lot more unnecessary bloat than is needed for caching a single int result from a function with no arguments. Its actually a lot slowe

[issue14478] Decimal hashing very slow, could be cached

Ramchandra Apte added the comment: I recommend that __hash__ should use functools.lru_cache for caching. -- nosy: +ramchandra.apte ___ Python tracker ___ ___

[issue14478] Decimal hashing very slow, could be cached

Stefan Krah added the comment: > but hashing will be faster. I retract that. The exponent actually makes things worse. -- ___ Python tracker ___ ___

[issue14478] Decimal hashing very slow, could be cached

Stefan Krah added the comment: I agree that caching the hash would be useful for 3.2, but the request comes at a unfortunate time: 3.2.3 is about to be released, and there's no way that the change would go into it. So let's focus on the C version in 3.3. These are the timings on a 64-bit machi

[issue14478] Decimal hashing very slow, could be cached

James Hutchison added the comment: 100x should be e100 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue14478] Decimal hashing very slow, could be cached

James Hutchison added the comment: If I increase the cycles increased 10x with 3.2 I get: int: 0.421313354492 Decimal: 24.20299983024597 CachingDecimal: 1.7809998989105225 The sample you have provided is basically what I'm using. See attached What about worst case hash calculation time

[issue14478] Decimal hashing very slow, could be cached

Serhiy Storchaka added the comment: It would be better if you provide a working script that demonstrates the issue. I have completed your example (attached). I ran the example on Python 3.1 and received: 0.24046326 9.8737308979 0.587980985641 Then I ran on Python 3.3: 0.2100839614868164

[issue14478] Decimal hashing very slow, could be cached

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue14478] Decimal hashing very slow, could be cached

Changes by R. David Murray : -- nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14478] Decimal hashing very slow, could be cached

New submission from James Hutchison : Tested on 3.2 Note that I noticed that Decimal is supposed to be faster in 3.3 but I thought I would bring this to light just in case its still relevant Decimal hashing is very slow, even for simple numbers. I found by caching the hash result, there is si