#715: Parents probably not reclaimed due to too much caching
--------------------------------+-------------------------------------------
Reporter: robertwb | Owner: somebody
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.8
Component: coercion | Keywords: weak cache coercion
Work_issues: Get some timings | Upstream: N/A
Reviewer: | Author: Simon King
Merged: | Dependencies: #9138, #11900
--------------------------------+-------------------------------------------
Comment(by SimonKing):
Replying to [comment:113 vbraun]:
> This is a bit hackish, but we could also store a strong reference as
before but manually `Py_DECREF` it by one. The eraser then has to make
sure that cache entries are removed when they fall out of use, or we'll
segfault....
How should the eraser know which entry is to be removed? I wouldn't like
to re-implement the weakref module...
At least on my machine, I have a regression. In order to avoid it, I am
now experimenting with some ideas to speed-up the access to dictionary
items: With my current patch, I do something like
{{{
if k1 is bucket[i]()
}}}
where `buchet[i]` is a weak reference. But calling the reference takes a
lot of time.
For example, since k1 is compared by identity (not equality), it might
make sense to store `id(bucket[i]())` as an attribute of the weak
reference. This is possible by `weakref.KeyedRef`. And `bucket[i].key` is
a bit faster than `bucket[i]()`.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/715#comment:114>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.