I forgot: I noticed that creating dict from a matrix N*2 is not
optimized for lists and tuples. Is this because creation from a
sequence2 is not much used?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
Well, it seems to work now, but the creation from a combined, without
holes, dict, is definitively faster no more. On the contrary, it is 2x
slower.
This is probably because
1. combined dicts needs only one memcpy
2. probably I wrong something in my code, since I need TWO Py_INCREF
for keys and
In the meanwhile, I updated the code of frozendict to the new 3.10
code. And here I need some help.
As you can see by the new benchs:
https://github.com/Marco-Sulla/cpython/blob/frozendict/frozendict/test/bench.txt
creation of frozendict is not faster anymore. This is because Inada
introduced
On Thu, Sep 17, 2020 at 11:50 PM Marco Sulla
wrote:
>
> I do not like code duplication, but dictobject.c has already a lot of
> duplicated copies of the same function for optimization (see
> lookdict).
lookdict is very special case. It is used for namespace lookup. It is
the performance critical
I've done a PR:
https://github.com/python/cpython/pull/22346
As you can see, changes are not dramatical, if you improve only kw
creation. Furthermore, IMHO insert_to_emptydict() can be removed,
since it speeds up the insertion of the first element, but slows down
all the others. I do something
On Thu, 17 Sep 2020 at 05:31, Inada Naoki wrote:
>
> On Thu, Sep 17, 2020 at 8:03 AM Marco Sulla
> wrote:
> >
> > python -m timeit -n 2000 --setup "from uuid import uuid4 ; o =
> > {str(uuid4()).replace('-', '') : str(uuid4()).replace('-', '') for i
> > in range(1)}" "dict(**o)"
> >
>
> I
On Thu, Sep 17, 2020 at 8:03 AM Marco Sulla
wrote:
>
> Well, it seems ok now:
> https://github.com/python/cpython/compare/master...Marco-Sulla:master
>
> I've done a quick speed test and speedup is quite high for a creation
> using keywods or a dict with "holes": about 30%:
30% on microbenchmark
Would an e.g. bm_dict.py in [1] be a good place for a few benchmarks of
dict; or is there a more appropriate project for authoritatively measuring
performance regressions and optimizations of core {cpython,} data
structures?
[1]
That sounds like a worthwhile optimization. FWIW, is this a bit simpler but
sufficient?:
python -m timeit -n 2000 --setup "from uuid import uuid4; \
o = {uuid4().hex: i for i in range(1)}" \
"dict(**o)"
Is there a preferred tool to comprehensively measure the performance impact
of a
Well, it seems ok now:
https://github.com/python/cpython/compare/master...Marco-Sulla:master
I've done a quick speed test and speedup is quite high for a creation
using keywods or a dict with "holes": about 30%:
python -m timeit -n 2000 --setup "from uuid import uuid4 ; o =
Well, I simply forgot vectorcall.
I've done a test and it seems the speedup is about 25%.
Unluckily, now I abandoned definitively the hope of a big big resize,
but it seems I don't resize correctly, since now I have again an
assert error on dk_usable.
What is the difference between dk_usable and
On Tue, 15 Sep 2020 at 09:22, Inada Naoki wrote:
>
> On Tue, Sep 15, 2020 at 5:08 AM Marco Sulla
> wrote:
> >
> > 1. How can we check the size of an object only if it's an iterable
> > using the Python C API?
>
> There is no good way. Additionally, we need to know distinct count if
> we want to
On Tue, Sep 15, 2020 at 5:08 AM Marco Sulla
wrote:
>
> 1. How can we check the size of an object only if it's an iterable
> using the Python C API?
There is no good way. Additionally, we need to know distinct count if
we want to preallocate hash table.
For example, `len(dict(["foo"]*1000))` is
@Inada (senpai?):
In the meanwhile I tried to apply some tricks to speedup the dict
creation without success.
This is my effort:
https://github.com/Marco-Sulla/cpython/blob/master/Objects/dictobject.c
As you can see, I simply "cloned" some functions that create dict, and
removed some checks that
On Wed, 29 Jul 2020 at 06:41, Inada Naoki wrote:
> FWIW, I optimized dict(d) in https://bugs.python.org/issue41431
> (https://github.com/python/cpython/pull/21674 )
> [...] 4.76x faster (-79%)
>
Great!
On Wed, 29 Jul 2020 at 06:41, Inada Naoki wrote:
> On Sun, Jul 26, 2020 at 4:44 AM Marco
On Sun, Jul 26, 2020 at 4:44 AM Marco Sulla
wrote:
>
> I also remembered another possible use-case: kwargs in CPython. In C code,
> kwargs are PyDictObjects. I suppose they are usually not modified; if so,
> fdict could be used, since it seems to be faster at creation.
>
I have not confirmed
On Sat, Jul 25, 2020 at 12:58 PM Guido van Rossum wrote:
> On Sat, Jul 25, 2020 at 12:45 PM Marco Sulla
> wrote:
>
>> I also remembered another possible use-case: kwargs in CPython. In C
>> code, kwargs are PyDictObjects. I suppose they are usually not modified; if
>> so, fdict could be used,
On Sat, Jul 25, 2020 at 12:45 PM Marco Sulla
wrote:
> I also remembered another possible use-case: kwargs in CPython. In C code,
> kwargs are PyDictObjects. I suppose they are usually not modified; if so,
> fdict could be used, since it seems to be faster at creation.
>
That's an interesting
On Thu, 23 Jul 2020 at 07:02, Yury Selivanov
wrote:
> If you're fascinated by functional programming then your version of
> the frozen dict should support efficient (not "O(n)") mutations.
>
Well, I tried it. No O(n), but the result is quite interesting.
Name: `o.set(key, value)`; Size:
On Wed, Jul 22, 2020 at 9:25 PM Marco Sulla
wrote:
<...>
> On Wed, 22 Jul 2020 at 18:26, Guido van Rossum wrote:
>>
>> Did you study PEP 416 (frozendict) and PEP 603 (frozenmap)?
>
>
> Yes. About frozenmap, at the very start I added to the benchmarks also
> immutables.Map, but I removed it when
20 matches
Mail list logo
