Can you post the full call graph after this fix (thanks Neil S!)
somewhere, or attach it to an email here?
--Guido
On 9/7/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> On 9/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > It should be set in unicode_hash(). If you compare the trunk versio
On 9/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It should be set in unicode_hash(). If you compare the trunk version
> of that function with the py3k branch version, you see that it's been
> refactored, and in the refactoring, setting ->hash was omitted. It
> should be trivial to put it ba
I'd like Tim Peters's input on this before we change it. I seem to
recall that there's an aspect of non-randomness to the existing hash
function that's important when you hash many closely related strings,
e.g. "0001", "0002", "0003", etc., into a dictionary. Though it's been
so long that I may mis
On 9/4/07, Thomas Hunger <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> I don't know much about python internals, so the following might be
> bogus:
>
> I replaced unicode_hash and string_hash with the hash function from
> here: http://www.azillionmonkeys.com/qed/hash.html.
>
> Then I ran the followin
On 9/6/07, Ivan Krstić <[EMAIL PROTECTED]> wrote:
>
> On Sep 6, 2007, at 4:09 AM, Martin v. Löwis wrote:
> > There are more issues, of course: some countries restrict the use
> > of cryptography. France is given as an example: you need to register
> > your cryptography keys with the government (SCS
It should be set in unicode_hash(). If you compare the trunk version
of that function with the py3k branch version, you see that it's been
refactored, and in the refactoring, setting ->hash was omitted. It
should be trivial to put it back.
On 9/7/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> Be
Before I do a bunch of searching around in the source, perhaps someone
just knows the answer to this question.
A quick trip through the debugger indicates that the reason
PyDict_GetItem is being called 5 million times more often in
PyEval_EvalFrameEx in 3.0 (in pystone 10) is because while
PyS
On Sep 7, 2007, at 1:24 PM, Georg Brandl wrote:
> Should the __future__ be cleaned out for 3k, or should all future
> imports
> continue to work and do nothing?
They should continue to work.
One advantage of keeping the existing feature table in the __future__
module is that is makes it easie
Should the __future__ be cleaned out for 3k, or should all future imports
continue to work and do nothing?
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eigh
On 9/3/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> NOTE: This data is time sampling, not call graph. Added time could
> come from either more calls, or longer calls.
>
> +312.9% PyDict_GetItem
I've finally managed to get call graph data and it's fairly
interesting for this call. I try to f
10 matches
Mail list logo
