Database options was (Re: My first Magma experience ...)

marcelo Cortez jmdc_marcelo at yahoo.com.ar
Tue Apr 5 15:24:09 UTC 2005


for reasons of perfomance the time of
OrderedCollections is better s to use
ODBTreedictionary, this  dictionaries are like
collection  but that use at: put protocol. the reason
is that in orderedCollection whenever you add
something you must keep all orderedCollection however
the dictionaries look like  tree, single store the
node
Keep use of OrderedCollection with caution , never put
OrderedCollection at root the entire container have 
poor perfomance for this razons
My mother language is not english , for this reasons i
response to you directcly sorry 

 hope this help 

 ;;)
 go smalltalk 
--- Daniel Salama <dsalama at user.net> wrote:
> I modified the free OmniBase to ignore the file
> locking in Linux for 
> the time being. Then I tried running the same
> benchmark I ran against 
> Magma and GOODS. I had a difficult time with
> OmniBase, I guess grasping 
> the concept of everything needing to be in a
> transaction, so I don't 
> know if my code is right. Can anyone tell me if this
> code would work 
> with OmniBase:
> 
> 	time := Time millisecondsToRun:
> 		[[db := OmniBase openOn: 'Macintosh
> HD:Users:dsalama:OB'.
> 		
> 		[OmniBase root at: 'FHKC834' put:
> (OrderedCollection new)]
> 			evaluateAndCommitIn: db newTransaction.
> 		
> 		[head := FHKC834Header new.
> 		head controlNumber: (self ediData controlNumber).
> 		head referenceNumber: (self ediData
> referenceNumber).
> 		head date: (self ediData date).
> 		head time: (self ediData time).
> 		head members: (OrderedCollection new).
> 
> 		theBase := OmniBase root at: 'FHKC834'.
> 		theBase add: ediData.
> 		theBase markDirty]
> 			evaluateAndCommitIn: db newTransaction.
> 			
> 		numCommits := 0.
> 		Transcript cr.
> 		
> 		1 to: (((ediData members) size) / 100 asFloat)
> ceiling do:
> 			[:lp |
> 			txn := db newTransaction.
> 			theBase := txn root at: 'FHKC834'.
> 			head := theBase first.
> 			
> 			1 to: 100 do:
> 				[:i |
> 				(self ediData members at: (lp - 1 * 100 + i))
> notNil
> 					ifTrue: [(head members) add: (self ediData
> members at: i)]].
> 			txn commit.
> 			numCommits := numCommits + 1.
> 			txn abort.
> 			Transcript show: '.']] ensure: [db close]].
> 	 db close.
> 
> 	Transcript cr; show: (time/1000) asFloat; show: '
> seconds to load into 
> GOODS in ';
> 		show: numCommits; show: ' commit(s)'.
> 
> It's supposed to commit every 100th element of the
> members attribute. 
> The reason I post this message is because it's been
> running for over 3 
> hours and it hasn't finished. I find it hard to
> believe that OmniBase 
> would take this long.
> 
> Thanks,
> Daniel
> 
> On Apr 4, 2005, at 12:27 PM, Avi Bryant wrote:
> 
> > On Apr 4, 2005 5:41 PM, Daniel Salama
> <dsalama at user.net> wrote:
> >> My understanding from David is that the
> commercial license does not
> >> have Linux file locking support. I'd be willing
> to buy a commercial
> >> license immediately if I knew the support for
> Linux was there.
> >
> > The second you have a commercial license, I can
> send you:
> >
> > - An up to date version of OmniBase (commercial)
> with the linux file
> > locking merged in
> > - The version of OSProcess it depends on
> > - A tarball of the unix VM source modified to work
> properly with 
> > OmniBase
> > - A prebuilt VM for Mac OS X with the above
> modifications (if that's 
> > useful)
> >
> > However, please do note that you can do a huge
> amount of evaluation,
> > testing and development *without* the locking
> support and *without*
> > using the commercial version... both of those are
> only things you
> > would really need for a deployment scenario.
> >
> > Avi
> 
> 
> 


	

	
		
___________________________________________________________ 
250MB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar



More information about the Squeak-dev mailing list