The way Ledger works right now, if you don't use sorting or subtotaling, I able to start reporting transactions *as they are parsed*, which means the speed of reporting the first few entries is unrelated to the length of the file. I wasn't ready to give that up just for the balance assertion logic, whose overall popularity I don't even know yet.
So yes, sorting may be acceptably fast, but I also don't want people to pay for a feature they never use, unless you convince me that balance assertions are being used by everyone. Lastly, how do you order three transactions on the same date from three different files, which may even be inter-dependent? John (from my iPhone) On Aug 3, 2013, at 7:01 AM, Harshad RJ <[email protected]> wrote: > > On Sat, Aug 3, 2013 at 12:50 PM, John Wiegley <[email protected]> wrote: >> unless I parse, sort, then process, > > I guess it is sorting that was very time consuming and hence you wanted to > avoid it. > > But on modern hardware, millions of records can be sorted / indexed in > milliseconds. > > I don't mean to criticize. Just trying to understand the reasons for ledger's > behavior so that I can avoid unseen pitfalls in date-ordered processing. > > -- > Harshad RJ > -- > > --- > You received this message because you are subscribed to the Google Groups > "Ledger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
