new html-acct-table patch [was Re: html-acct-table patch]

Mike Alexander mta at
Wed Oct 31 17:25:50 EDT 2007

--On October 31, 2007 1:00:14 PM -0700 Andrew Sackville-West 
<ajswest at> wrote:

> On Wed, Oct 31, 2007 at 01:34:57PM -0400, Mike Alexander wrote:
>> The main
>> difference is to use a hash table instead of a list to save the
>> account  balances.  This cuts another 11% or so off the time for my
>> balance sheet  report.
> I read up a bit on hash-tables and have some questions/comments. These
> are genuine questions, and not criticism of your code, so please help
> me learn here...
> +      (calculate-balances-helper accts start-date end-date
> +                                 (make-hash-table 23))
> you have arbitrarily (it appears) set the hash table to 23
> slots. Granted, a hash table can grow, and for these purposes it
> doesn't matter what size it really is. But since we can easily count
> the number of slots needed, why not do that? or if you don't want to
> bother counting it, it is a reasonable assumption there will be 1
> acct, so why not make it 1? I do understand that it should be a prime
> number for some reason I don't understand... but I'm curious.

That's the number of hash buckets, not the number of entries in the 
hash table.  One normally sets the number of hash buckets to a prime 
number such that each bucket contains only a few entries.  This 
parameter to make-hash-table is optional and it might be better to just 
leave it out and let it figure out the number of buckets.

> +                (hash-set! acct-balances (gncAccountGetGUID (car
> accts)) +                    (get-balance-nosub-mode (car accts)
> start-date end-date))
> per, hash-set!
> finds the key in table and assigns the value to that slot. So this
> implies that the key already exists. What happens if the key doesn't
> exist? In this case, it appears that the key gets created and the
> value stored. But this is not stated and appears to be a side-effect
> of whtat the functionis supposed to do. It seems to me that this
> behavior may not be guaranteed and it may be better to use something
> like
> (hash-create-handle! acct-balances ...)
> since that's what its designed for. It would suck to have guile decide
> to change behavior with regards to hash-set! and start just returning
> a #f or something instead of creating the new handle. your comments
> are appreciated.

The description of hash-set! that I found is

> Associate val with key in the given hash table. If key is already
> present then it's associated value is changed. If it's not present
> then a new entry is created.

This seems to be what I wanted so I used it.  Granted that the key 
should never already be in the table, but if it is replacing it seems 
like the right thing to do.  Using hash-create-handle! would probably 
be ok too since it shouldn't be in the table already and they are 
equivalent (except for the return value) in this case.

As usual there are lots of different ways to accomplish the same thing. 
I picked one, but it was largely an arbitrary decision.


More information about the gnucash-devel mailing list