Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!cam-news-feed3.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!news.mathworks.com!enews.sgi.com!news.sgi.com!news1.best.com!noos.hooked.net!news.scruz.net!cruzio.com!news
From: jordan@cruzio.com (Jordan Bortz)
Subject: Re: [VW] A faster BOSS?
X-Newsreader: Forte Free Agent 1.0.82
Reply-To: jordan@cruzio.com
Sender: news@cruzio.com (System Administrator)
Organization: Object Productions Inc
Message-ID: <E5qss5.HGK@cruzio.com>
References: <33035F11.2B60@integral.com> <33062A18.1099@mindspring.com>
X-Nntp-Posting-Host: mbay5.cruzio.com
Date: Mon, 17 Feb 1997 07:16:20 GMT
Lines: 62

There are several reasons why BOSS is slow, and a few ways to overcome
those problems...certainly the suggestion to use onOldNoScan: when
reading in files is a good one, but that only saves time during the
open file phase, and not any other...

The biggest reasons why BOSS is slow is:
	1) No indexing of individual objects
	2) Objects written out tend to be larger than necessary
	3) Instantiating large amounts of fresh objects is an expensive
operations, Smalltalk wise
	4) The encoder/decoder code is slow...

Problems 1 & 2 are the crux of the problem -- to get at a particular
object, one has to read through tons of irrelevant objects in a
streaming fashion... If these objects are huge, it will take a long
time and a lot of memory to get to the desired object.

The solution to this problem, as well as a few other BOSS problems, is
to use a product which provides indexing for BOSS, such as our Tigris
product.

Tigris allows users to easily store objects in and out of a Tigris
database (a souped up BOSS system), in a true random access fashion.
This avoids the needless overhead of slogging through a huge object
stream.

Tigris is also multi-user and supports locking in a networking
environment...Its also reasonably priced at less than $500 per
developer...

	Jordan
Object Productions Inc

Thomas Thornbury <thornburyt@mindspring.com> wrote:

>Gary-

>Since you don't mention how you're using BOSS, it's hard to suggest ways 
>to speed it up.   However, here's one way to improve retrieval speed if 
>you're not already doing it.

>Turn off the scanning of old BOSS files.   Instead of creating your 
>reader using just onOld: aStream use onOldNoScan: aStream.

>If you're already doing this, you can replace the class used for reading 
>with an optimized ReaderClass.

>-tlt

>Viral Tolat wrote:

>> 
>> Suppose you have an application with simple persistence requirements.
>> BOSS looks ideal, except in one respect: retrieval speed.
>> 
>> Does anyone know of any attempts to tweak BOSS to improve its
>> performance - even to the extent of changing the binary format to trade
>> space for speed?
>> 
>> -- Gary Birch


