eriknw / toolz

100%

master: 100%

LAST BUILD ON BRANCH faster_unique

branch: faster_unique

CHANGE BRANCH

x

Reset

• faster_unique
• authors_larsmans_josericardo
• authors_shvechikov
• backport_tests
• better_curry_error
• better_curry_introspection
• clean_curried_namespace
• consume
• correct_flip_doctest
• coveralls
• coveralls_for_master
• coveralls_success_only
• curry_class
• curry_classmethods
• curry_makeover
• curry_memoize
• curry_numargs
• curry_reduce
• dict_iter
• diff
• equality_hash_key
• explicit_curried
• faster_groupby
• faster_merge_sorted
• faster_merge_with
• faster_remove
• fix/curry_module
• fix/ensure_easy_testing
• fix_32bit_overflow
• fix_property_introspection
• get_with_itemgetter
• identical
• isdistinct_for_iterators
• itemmap
• jackknife_sandbox
• juxt_generator
• juxt_tuple
• last_with_deque
• memoize_key_func
• memoize_unary
• more_introspection
• nth_with_list
• pep479
• pypy3
• python3.6
• readme_broken_links
• readme_rst
• remove_jackknife
• run_doctests_on_curried
• serialize_juxt
• svg_badges
• test_curry_too
• test_dicttoolz_types
• tlz
• unused_variables
• update/pluck_docstring

Build # 86

Build Type

push

travis-ci

Committed by eriknw

Commit Message

Faster unique, isdistinct, merge_sorted, and sliding_window.

The `key` keyword argument to `unique` was changed from `identity` to `None`.
This better matches API elsewhere, and lets us remove `identity` from being
redefined in `itertoolz`, which always seemed a little weird.

Most of the speed improvements come from avoiding attribute resolution in
frequently run code.  Attribute resolution (i.e., the "dot" operator) is
probably more costly than one would expect.  Fortunately, there weren't
many places to apply this optimization, so impact on code readability was
minimal.

`unique` employs another optimization: branching by `key is None` outside the
loop (thus requiring two loops).  While this violates the DRY principle (and,
hence, I would prefer not to do it in general), this is only a few lines of
code that remain side-by-side, and the performance increase is worth it.

`merge_sorted` is now optimized when only a single iterable remains.  This
makes it *so* much faster while in this condition.

Run Details

467 of 467 relevant lines covered (100.0%)

4.0 hits per line