It seems r67740 shouldn't have been committed. Since this
is a severe regression, I think I'll have to revert it, and
release 2.5.4 with just that change.
Unless I hear otherwise, I would release Python 2.5.4
(without a release candidate) tomorrow.
Regards,
Martin
On 2008-12-20 23:16, Martin v. Löwis wrote:
I will try next week to see if I can come up with a smaller,
submittable example. Thanks.
These long exit times are usually caused by the garbage collection
of objects. This can be a very time consuming task.
I doubt that. The long exit times are
On Mon, Dec 22, 2008 at 10:06 AM, chojra...@gmail.com wrote:
On Mon, Dec 22, 2008 at 03:29, Guilherme Polo ggp...@gmail.com wrote:
On Sun, Dec 21, 2008 at 11:02 PM, chojra...@gmail.com wrote:
Hello,
I'm trying to implement custom exception that have to carry some
useful info by means of
On Mon, Dec 22, 2008 at 10:45 AM, Guilherme Polo ggp...@gmail.com wrote:
On Mon, Dec 22, 2008 at 10:06 AM, chojra...@gmail.com wrote:
On Mon, Dec 22, 2008 at 03:29, Guilherme Polo ggp...@gmail.com wrote:
On Sun, Dec 21, 2008 at 11:02 PM, chojra...@gmail.com wrote:
Hello,
I'm trying to
Martin It seems r67740 shouldn't have been committed. Since this is a
Martin severe regression, I think I'll have to revert it, and release
Martin 2.5.4 with just that change.
Martin Unless I hear otherwise, I would release Python 2.5.4 (without a
Martin release candidate)
Should we add this to the active branches (2.6, trunk, py3k, 3.0)?
Sure! Go ahead.
For 2.5.3, I'd rather not add an additional test case, but merely
revert the patch.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Dec 22, 2008, at 9:35 AM, s...@pobox.com wrote:
I don't think there is a test case which fails with it applied and
passes
with it removed. If not, I think it might be worthwhile to write
such a
test even if it's used temporarily just to test the change. I wrote a
trivial test case:
If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 19, 2008, at 9:44 PM, Martin v. Löwis wrote:
Do you think we can get 3.0.1 out on December 24th?
I won't have physical access to my build machine from December 24th to
January 3rd.
Okay. Let's just push it until after the new year
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 21, 2008, at 6:56 AM, Dmitry Vasiliev wrote:
Barry Warsaw wrote:
Thanks. I've bumped that to release blocker for now. If there are
any
other 'high' bugs that you want considered for 3.0.1, please make the
release blockers too, for now.
Barry Warsaw barry at python.org writes:
Please make sure these issues are release blockers. Fixes before
January 5th would be able to make it into 3.0.1.
Should http://bugs.python.org/issue4486 be a release blocker as well?
(I don't think so, but...)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 22, 2008, at 11:38 AM, Antoine Pitrou wrote:
Barry Warsaw barry at python.org writes:
Please make sure these issues are release blockers. Fixes before
January 5th would be able to make it into 3.0.1.
Should
Thanks for all of the useful suggestions. Here are some preliminary results.
With still gc.disable(), at the end of the program I first did a
gc.collect(), which took about five minutes. (So, reason enough not
to gc.enable(), at least without Antoine's patch.)
After that, I did a .clear() on
On Mon, Dec 22, 2008 at 6:20 AM, M.-A. Lemburg m...@egenix.com wrote:
BTW: Rather than using a huge in-memory dict, I'd suggest to either
use an on-disk dictionary such as the ones found in mxBeeBase or
a database.
I really want this to work in-memory. I have 64G RAM, and I'm only
trying to
On Mon, Dec 22, 2008 at 11:01 AM, Mike Coleman tutu...@gmail.com wrote:
Thanks for all of the useful suggestions. Here are some preliminary results.
With still gc.disable(), at the end of the program I first did a
gc.collect(), which took about five minutes. (So, reason enough not
to
Or perhaps there's a smarter way to manage the list of
arena/free pool info.
If that code is the real problem (in a reproducible test case),
then this approach is the only acceptable solution. Disabling
long-running code is not acceptable.
Regards,
Martin
On Mon, Dec 22, 2008 at 2:38 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Or perhaps there's a smarter way to manage the list of
arena/free pool info.
If that code is the real problem (in a reproducible test case),
then this approach is the only acceptable solution. Disabling
long-running
On Dec 22, 2008, at 1:13 PM, Mike Coleman wrote:
On Mon, Dec 22, 2008 at 6:20 AM, M.-A. Lemburg m...@egenix.com wrote:
BTW: Rather than using a huge in-memory dict, I'd suggest to either
use an on-disk dictionary such as the ones found in mxBeeBase or
a database.
I really want this to work
On 2008-12-22 19:13, Mike Coleman wrote:
On Mon, Dec 22, 2008 at 6:20 AM, M.-A. Lemburg m...@egenix.com wrote:
BTW: Rather than using a huge in-memory dict, I'd suggest to either
use an on-disk dictionary such as the ones found in mxBeeBase or
a database.
I really want this to work
If that code is the real problem (in a reproducible test case),
then this approach is the only acceptable solution. Disabling
long-running code is not acceptable.
By disabling, I meant disabling the optimization that's trying to
rearrange the arenas so that more memory can be returned to
2008/12/22 Guilherme Polo ggp...@gmail.com:
On Mon, Dec 22, 2008 at 10:06 AM, chojra...@gmail.com wrote:
#include Python.h
static PyObject *MyErr;
static PyMethodDef module_methods[] = {
{raise_test1, (PyCFunction)raise_test1, METH_NOARGS, NULL},
{raise_test2,
On Dec 22, 2008, at 4:07 PM, M.-A. Lemburg wrote:
What kinds of objects are you storing in your dictionary ? Python
instances, strings, integers ?
Answered in a previous message:
On Dec 20, 2008, at 8:09 PM, Mike Coleman wrote:
The dict keys were all uppercase alpha strings of length 7. I
Not this list, sorry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Hello snakemen and snakewomen
I'm Pascal Chambon, a french engineer just leaving my Telecom School,
blatantly fond of Python, of its miscellaneous offsprings and of all
what's around dynamic languages and high level programming concepts.
I'm currently studying all I can find on stackless
On Mon, 22 Dec 2008 11:20:59 pm M.-A. Lemburg wrote:
On 2008-12-20 23:16, Martin v. Löwis wrote:
I will try next week to see if I can come up with a smaller,
submittable example. Thanks.
These long exit times are usually caused by the garbage collection
of objects. This can be a very
Investigating further, from one stop, I used gdb to follow the chain
of pointers in the nextarena and prevarena directions. There were
5449 and 112765 links, respectively. maxarenas is 131072.
To reduce the time for keeping sorted lists of arenas, I was first
thinking of a binheap. I had
I have this trivial little test case for test_file.py:
+def testReadWhenWriting(self):
+self.assertRaises(IOError, self.f.read)
I would like to add it to the 2.6 and 3.0 maintenance branch and the 2.x
trunk and the py3k branch. What is the preferred way to do that? Do I
On Mon, Dec 22, 2008 at 4:02 PM, s...@pobox.com wrote:
I have this trivial little test case for test_file.py:
+def testReadWhenWriting(self):
+self.assertRaises(IOError, self.f.read)
I would like to add it to the 2.6 and 3.0 maintenance branch and the 2.x
trunk and the
I'm currently studying all I can find on stackless python, PYPY and the
concepts they've brought to Python, and so far I wonder : since
stackless python claims to be 100% compatible with CPython's extensions,
faster, and brings lots of fun stuffs (tasklets, coroutines and no C
stack), how
I would like to add it to the 2.6 and 3.0 maintenance branch and the 2.x
trunk and the py3k branch. What is the preferred way to do that? Do I
really have to do the same task four times or can I check it in once (or
twice) secure in the belief that someone will come along and do a monster
Martin v. Löwis martin at v.loewis.de writes:
It then occurred that there are only 64 different values for nfreepools,
as ARENA_SIZE is 256kiB, and POOL_SIZE is 4kiB. So rather than keeping
the list sorted, I now propose to maintain 64 lists, accessible in
an array double-linked lists
Allocation of a new pool would have to do a linear search in these
pointers (finding the arena with the least number of pools);
You mean the least number of free pools, right?
Correct.
IIUC, the heuristic is to favour
a small number of busy arenas rather than a lot of sparse ones.
On Mon, Dec 22, 2008 at 2:54 PM, Ivan Krstić
krs...@solarsail.hcs.harvard.edu wrote:
It's still not clear to me, from reading the whole thread, precisely what
you're seeing. A self-contained test case, preferably with generated random
data, would be great, and save everyone a lot of
On Mon, Dec 22, 2008 at 2:22 PM, Adam Olsen rha...@gmail.com wrote:
To make sure that's the correct line please recompile python without
optimizations. GCC happily reorders and merges different parts of a
function.
Adding a counter in C and recompiling would be a lot faster than using
a gdb
On Dec 22, 2008, at 6:28 PM, Mike Coleman wrote:
For (2), yes, 100% CPU usage.
100% _user_ CPU usage? (I'm trying to make sure we're not chasing some
particular degeneration of kmalloc/vmalloc and friends.)
--
Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org
Now, we should find a way to benchmark this without having to steal Mike's
machine and wait 30 minutes every time.
So, I seem to reproduce it. The following script takes about 15 seconds to
run and allocates a 2 GB dict which it deletes at the end (gc disabled of
course).
With 2.4, deleting
Benjamin If you check it into the trunk, it will find it's way into
Benjamin 2.6, 3.1, and 3.0.
Outstanding!
Thx,
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Steven D'Aprano wrote:
This behaviour appears to be specific to deleting dicts, not deleting
random objects. I haven't yet confirmed that the problem still exists
in trunk (I hope to have time tonight or tomorrow), but in my previous
tests deleting millions of items stored in a list of
2008/12/22 Ivan Krstić krs...@solarsail.hcs.harvard.edu:
On Dec 22, 2008, at 6:28 PM, Mike Coleman wrote:
For (2), yes, 100% CPU usage.
100% _user_ CPU usage? (I'm trying to make sure we're not chasing some
particular degeneration of kmalloc/vmalloc and friends.)
Yes, user. No noticeable
I unfortunately don't have time to work out how obmalloc works myself,
but I wonder if any of the constants in that file might need to scale
somehow with memory size. That is, is it possible that some of them
that work okay with 1G RAM won't work well with (say) 128G or 1024G
(coming soon
Mike Coleman wrote:
If you plot this, it is clearly quadratic (or worse).
Here's another comparison script that tries to probe the vagaries of the
obmalloc implementation. It looks at the proportional increases in
deallocation times for lists and dicts as the number of contained items
increases
On Mon, Dec 22, 2008 at 7:34 PM, Antoine Pitrou solip...@pitrou.net wrote:
Now, we should find a way to benchmark this without having to steal Mike's
machine and wait 30 minutes every time.
So, I seem to reproduce it. The following script takes about 15 seconds to
run and allocates a 2 GB
Martin Instead, you should commit it into trunk, and then run svnmerge.py
three
Martin times, namely:
...
Thanks for that cheat sheet. I never would have figured that out on my
own. Well, at least not in a timely fashion.
Skip
___
Martin v. Löwis wrote:
It seems r67740 shouldn't have been committed. Since this
is a severe regression, I think I'll have to revert it, and
release 2.5.4 with just that change.
My understanding of the problem is that clearerr() needs to be called
before any FILE read operations on *some*
I am hoping someone can assist me. I normally don't care if the _ctypes
module builds or not, but I now need to have it build.
I am running Solaris 10 with Sun's C compiler under SunStudio 11.
After running 'configure' and 'make', the _ctypes module fails with the
following error:
cc
44 matches
Mail list logo
