Hi all, [MAL] > >>>>> "M" == M <mal@lemburg.com> writes: > > M> I don't understand why we cannot take the risk of trying this > M> out in an alpha version. Because the risk (long-term) is kind of unknown. obmalloc works fine, and it speeds things up, yes, in most setups or circumstances. It gains that speed from the Python core "memory pattern", which is by far the dominant, no matter what the app is. Tim's statement about my profiling is kind of a guess (Hi Tim!) [Barry] > > Logistically, we probably need BDFL pronouncement on this and if we're > to get alpha2 out today, that won't happen in time. If we don't get > the alpha out today, we probably will not get the first beta out by > IPC9, and I think that's important too. > > So I'd be +1 on adding it opt-in for beta1, which would make the code > available to all, and allow us the full beta cycle and 2.2 development > cycle to do the micro benchmarks and evaluation for opt-out (or simply > always on) in 2.2. I'd say, opt-in for 2.1. No risk, enables profiling. My main reservation is about thread safety from extensions (but this could be dealt with at a later stage) + a couple of other minor things I have no time to explain right now. But by that time (2.2), I do plan to show up on a more regular basis. Phew! You guys have done a lot for 3 months. I'll need another three to catch up <wink>. Cheers, Vladimir
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