y:
*f = open('f', 'wb')*
*pickle.dump(l, f)*
*f.close()*
*print pickle.load(open('f', 'rb'))*
Apparently, in the first code snippet, the file isn't closed as it should
be when the object returned by open() goes out of scope after pic
ation runs on a
host with lots of ram, can be restarted fairly often, and real-time
performance is preferable to blocking because of garbage collection.
I have tried just removing the body of
incminimark.py/major_collection_step(), but this causes pypy to freeze up
after a while.
Thanks,
/Martin
, Mar 18, 2014 at 11:23 AM, Carl Friedrich Bolz wrote:
> Agreed, somehow this should not happen.
>
> Anyway, I'm not the person to look into this, but I filed a bug, so at
> least your example code does not get lost:
>
> https://bugs.pypy.org/issue1710
>
> Cheers,
&g
have no effect.
I'm looking forward to the results of the Software Transactional Memory,
btw :)
/Martin
On Tue, Mar 18, 2014 at 9:47 AM, Carl Friedrich Bolz wrote:
> On 17/03/14 20:04, Martin Koch wrote:
> > Well, it would appear that we have the problem because we're gene
y same for gc-walkroots and
> gc-collect-step)
>
>> On Mon, Mar 17, 2014 at 4:19 PM, Martin Koch wrote:
>> Here are the collated results of running each query. For each run, I count
>> how many of each of the pypy debug lines i get. I.e. there were 668 runs
>> that p
then. I don't exactly know
> why, but you should look what objects can potentially survive for too
> long.
>
>> On Mon, Mar 17, 2014 at 5:37 PM, Martin Koch wrote:
>> Ah - it just occured to me that the first runs may be slow anyway: Since we
>> take the average of t
an you do two things:
> >
> > a) take a max of gc-minor (and gc-minor-stackwalk), per request
> > b) take the sum of those
> >
> > and plot them
>
> ^^^ or just paste the results actually
>
> >
> > On Mon, Mar 17, 2014 at 3:18 PM, Martin Koch wro
le PYPYLOG=gc:- (where - is stdout)
> which will do that for you btw.
>
> maybe you can find out what's that using profiling or valgrind?
>
> On Sun, Mar 16, 2014 at 11:34 PM, Martin Koch wrote:
> > I have tried getting the pypy source and bui
On Mon, Mar 17, 2014 at 1:53 PM, Maciej Fijalkowski wrote:
> I think it's the cycles of your CPU
>
> On Mon, Mar 17, 2014 at 2:48 PM, Martin Koch wrote:
> > What is the unit? Perhaps I'm being thick here, but I can't correlate it
> > with seconds (which the
t 12:09 PM, Maciej Fijalkowski wrote:
> The number of lines is nonsense. This is a timestamp in hex.
>
> On Mon, Mar 17, 2014 at 12:46 PM, Martin Koch wrote:
> > Based On Maciej's suggestion, I tried the following
> >
> > PYPYLOG=- pypy mem.py 1000 > out
e, so it is
somehow related to either GC or the runtime somehow.
Cheers,
/Martin
On Fri, Mar 14, 2014 at 4:19 PM, Martin Koch wrote:
> We have hacked up a small sample that seems to exhibit the same issue.
>
> We basically generate a linked list of objects. To increase connectedness,
time):
print "that took a long time elapsed: %f slow_threshold:
%f 90th_quantile_runtime: %f" % \
(elapsed, slow_time,
sorted(timings)[int(num_timings*.9)])
i += 1
print total
On Thu, Mar 13, 2014 at 7:45 PM, Maciej Fijalkowski wrote:
&g
Hi Armin, Maciej
Thanks for responding.
I'm in the process of trying to determine what (if any) of the code I'm in
a position to share, and I'll get back to you.
Allowing hinting to the GC would be good. Even better would be a means to
allow me to (transparently) allocate objects in unmanaged me
shouldn't
that avoid long pauses due to garbage collection?
Thanks,
/Martin Koch - Senior Systems Architect - issuu.com
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
14 matches
Mail list logo
