"Martin v. Loewis" wrote: > > I just performed some benchmark of pymalloc, compared to glibc 2.2 > malloc, using xmlproc (a pure-Python XML parser) as the sample > application. On an artificial input document, the standard > configuration ran 16.3s; the configuration with pymalloc ran 15s. > > I recommend to enable pymalloc by default; I can commit the necessary > changes if desired. I had some issues w/purify & pymalloc (1000s of warnings). I think these problems were documented under the thread: * [Python-Dev] Mixing memory management APIs in January and February (definitely in Feb). I don't think they have been fixed. I can't remember all the issues (sometimes it was pymalloc, other times it was unicode). So I may be mixing some things up. Part of the problem was the code in Modules/sre.h:16: /* size of a code word (must be unsigned short or larger, and large enough to hold a Py_UNICODE character) */ #ifdef Py_UNICODE_WIDE #define SRE_CODE unsigned long #else #define SRE_CODE unsigned short #endif #define SRE_CODE unsigned short Notice SRE_CODE is always set to unsigned short. I don't know what is correct. I can re-run purify. Although, I have a crappy beta, so I don't know if it will be useful or not. Neal
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4