This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Saving some memory Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

I made a small change in the BottomFeeder development stream last night that eases the memory consumption of the application. The HTTP client library we use, Net Resources, has two levels of cache - disk and in-memory. Up until now, the application has been keeping that cache in memory as it ran. What I've done is added a setting - if it's false (the default), then the cache is not held in memory (except during the update loop) - it's only on disk. For my running copy, that dropped the appetite of the app by nearly 20 MB.

Michael has started looking at making the content for cached items demand loaded (instead of the current all in memory model). I doubt I'll get that into the soon to be released 3.8 - it's too radical a change. Once we get that in, it should lower the runtime footprint of Bf dramatically.

Another comment I've gotten has been on the cpu load during the update loop - grabbing the RSS feeds and processing them in a threaded update loop is fast, but it can be expensive in memory and cpu terms. I added an option awhile back that lets you slow that down - if you look under Settings>>Network, check the Slower Update Cycle option and turn threaded updates off. What that will do is sequence the updates across the update interval you've chosen. So, say you subscribe to 60 feeds, and you have set the cycle to 60 minutes. If you toggle the settings as listed above, each http query will be separated by a minute - and when they are all done, there will be an hour's delay before the next update. This was in response to numerous requests, and setting it up that way should make the application less resource intensive as well.