GOODS

> Avi Bryant wrote:
>> So you're finding that writes are the main bottleneck, and that read
>> performance is fine?  I'd be curious to hear more about this; in my
>> own limited experiments the read performance was what concerned me
>> most.
>>
> I have tuned the read code a bit (at the expense of support for  
> arbitrary GOODS class name -> Smalltalk class name mappings) and  
> that has improved the only problems I've had with reads.  I think  
> we're getting close to being limited by network issues.  I believe  
> that GOODS supports talking on a UNIX domain socket so it might be  
> interesting to see if that would improve things much.  It hasn't  
> been an issue for me though.  For applications where you rapidly  
> populate large models you might run into trouble...I don't have any  
> examples of that.  I worked on an app last year, which never saw the  
> light of day unfortunately, where we had a fair number of large  
> binary objects (png's and morphs) stored in GOODS and reads were a  
> bit sluggish.  "a bit" here meant not bad enough compared to non-
> GOODS related problems to be worth the time to investigate.  I've  
> found tweaking the server.cluster_size parameter can also help to  
> alleviate read-related performance problems.
>
> Performance problems with GOODS, in my experience, are typically:
>
>   1) connection time so I keep a pool of fresh connections around
>   2) writes when the cache is large or when you have large objects  
> to compare (arrays, for example) -- this requires some clever  
> flushing strategies to fix when it occurs
>
> WriteBarrier seemed promising to fix #2 but it causes all kinds of  
> other problems for me.  I had hoped to have funding to pay someone  
> to implement VM-level immutability support in Squeak...that would  
> solve the problem without bytecode tricks.  But that funding fell  
> through with the aforementioned project.  I think such a thing would  
> substantially benefit GOODS and Magma.