-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Add tqdm_bare and tbrange as minimal example for ports developers #258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #258 +/- ##
=========================================
Coverage ? 57.76%
=========================================
Files ? 9
Lines ? 1018
Branches ? 227
=========================================
Hits ? 588
Misses ? 428
Partials ? 2 Continue to review full report at Codecov.
|
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
I stop here, I'll add unit tests if enough people are interested. (Adding unit tests shouldn't be too hard because we can reuse the tests of core tqdm but some specs were changed because I stripped down some stuff and checks or because it wasn't possible without a class, such as move and refresh nested bars display when a bar closes, so the spec here is that new bars will fill up empty spaces or if not possible will be appended below). |
…ine update code in iterable mode (optimization) Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
I did some benchmark against different versions of tqdm:
All bars were benchmarked with So as we can see, tqdm_bare is somewhat as fast as all the other bars, except class (tqdm v2.0) which is significantly slower than tqdm_bare. Note that core tqdm is still sensibly faster than tqdm bare, which shows once again that we did a pretty good job at optimizing core tqdm. But I don't know why this is so, since there is technically less opcodes, so my guess is that the function based approach with closures is slower than a class based approach when we implement some of the major features of tqdm. I'm going to try to reimplement tqdm_bare with a class based approach and see if it speeds up a bit (because if that's the case, a class-based approach is anyway easier to read so that would be better all around). |
@lrq3000 so |
v1.0 was slooooooow. easy to beat |
Signed-off-by: Stephen L. <lrq3000@gmail.com>
@casperdcl I mean slower |
For comparison:
@casperdcl v1.0 was the fastest in all of them. And @lrq3000 optimizations apparently made it slower. Slowest is class. |
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
I also now think we should keep both, because the new goal of this submodule is to provide a simplified version for porting to other languages, and non-object-oriented languages will benefit from What do you think about it @casperdcl ? Should we keep both? |
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
# Conflicts: # tqdm/__init__.py Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
I merged both in the same branch, it will be easier to review, compare and test. |
8cade97
to
a65e347
Compare
oh yes, nice. I'd agree that we should have both a class and a functional approach for future ref. Probably would merge this in after the next major release since it doesn't actually add features though. |
Ok great :) yes every new submodules should be merged after the new
|
6ec00f1
to
4b6476a
Compare
Implement what was asked in #255.
This PR implements a barebone tqdm with only the basic features. The goal is twofold: maximum speed and a short and easy implementation that other languages can use as a base to implement a minimalist
tqdm
.I made the choice of keeping it a function with closures. I think this is the best way to maximize performance. But it will impose severe implementation constraints. /EDIT: reimplemented with class-based approach in branch tqdm_bare_class, so we now have both approaches and must choose one!
/EDIT: I realized it's stupid to try to implement a tqdm_bare only for performance reasons, because if we strip out features to the bare, of course the opcode count will drop down significantly but the overhead will rise up: for example,
dynamic_miniters
wouldn't be implemented, which means that by defaultminiters=1
. In this case, even if tqdm_bare has fewer opcodes than core tqdm, it would be far slower because it would have a bigger overhead, checking time and printing more often than core tqdm does! And that's normal, core tqdm is already heavily optimized, most features are optional with virtually no cost.So, since minimizing opcodes is useless, I tried to minimize code statements: the new goals of this module are:
tqdm
in the fastest way possible.._utils
except to standard lib): the file should contain all logic necessary to reimplement it elsewhere. (I exceptionally call._utils
to load colorama because I think it's not part of our logic but rather a workaround for Windows console limitations.)The final objective is to have a standalone shortened tqdm containing major features as a minimal example for developers working on ports to other languages.
So here we are: tqdm_bare is 387 lines long including docstrings, comments and spaces and it supports major tqdm features that we love it for, such as automagic nested loops support!
Examples:
Supported arguments/features (including
dynamic_miniters
):Same for
tqdm_bare_class
(and same performance, etc.).TODO:
_tqdm_bare.py
and_tqdm_bare_class.py
. Thus, this will show two different ways of implementing tqdm in other languages, depending on whether the language is functional oriented or object oriented._tests_tqdm.py
? Or use old ones from v1.0-2.0?). Goal is to have 100% coverage like core tqdm.smoothing
(Exponential Moving Average)? (But remember that we don't want to reinvent the wheel, we already have core tqdm).benchmark.py
script?)