On Thu, Feb 14, 2019 at 2:44 AM Stefano Zacchiroli <[email protected]> wrote:
> On Sun, Feb 10, 2019 at 11:07:03PM -0500, Martin Blais wrote: > > You can view the breakdown in time with the -v option to bean-check: > > You've probably already thought about that, so out of curiosity: how > much of this is potentially parallelizable, as an avenue for "easily" > getting a performance boost? I guess not much, due to either I/O > constraints or the GIL lock, right? I'm curious about whether > validation, booking, and plugins might be made parallelizable in the > future. > None. It's a sequential process. Something that /might/ have an impact is to sequence all the operations as a chain of streams consuming each other (think: generators/iterators), for memory locality, but at this (small) scale I doubt it would make any difference TBH. Some of the plugins do multiple passes over the stream, which makes this not work and would require pirouettes to harvest opportunities for reusing already computed quantities (e.g. results of stuff from getters.py) No, I think what should be done for the next major release is a rewrite. At the very coarse level, it looks like this in my mind: - Beancount reports/web gets deleted in favor of Fava. - Beancount query/SQL gets forked to a separate project operating on arbitrary schemas (via protobufs as common representation for various sources of data) and has support for Beancount integration (e.g. a Decimal type, and simple aggregators with the semantics of beancount.core.Inventory/Position/Amount). That's all that's needed, and it would enable the query language to work on CSV files and other data sources. Moreover, this version would be tested property, and have data types in its compiler (no exceptions at runtime). - Beancount core, parser, booking and plugins get rewritten in simple C++ (no boost/templates, but rather on top of a bazel + absl + protobuf + clif base with functional-style and a straightforward subset of C++, no classes), providing its parsed and booked contents as a stream of protobuf objects. - All tests would remain in Python (I'm not rewriting those). Comprehensive clean Python bindings for beancount.core would be provided, to do as much scripting as is done today, except with types implemented fully in C++. - Moreover, all the big ticket items would have to be addressed, e.g. explicitly setting the precision instead of inference, currency trading accounts, reports of trades built-in, etc. -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhMXqd9sOAey%2B3aFDi6gh22B5bG8Y08E7CKa5WssWcryZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
