<br><div class="gmail_quote">On Thu, Dec 9, 2010 at 10:59 PM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com">ma.chris.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Yes, I'm not surprised that takes 3 minutes. The first problem is<br>
that you are using an invalid operator in your where. You must use<br>
"equals:", not "=". But the bigger problem is the design. There is<br>
overhead to using #where:, especially when using a disjuction or<br>
sorting or eliminating duplicates. End-user search and querying is<br>
the primary use-case for the #where: operations, not using Magma as a<br>
RDBMS to "look-up" single objects by a key value. </blockquote><div><br></div><div>Yes, I don't need that look up when I navigate or use my model but in this case I'm doing a bulk load so I don't if I can avoid the look-up by a key.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> The right<br>
collection for that job is MagmaPreallocatedDictionary, which can be<br>
large (millions) and still provide very fast #at: access to one object<br>
at a time. I do not recommend MagmaDictionary or MagmaSet where<br>
performance is at all concerned. For that reason these collections<br>
really deserve to be deprecated and deleted from Magma.<br></blockquote><div><br></div><div>Well to know, I'm going to try it with MagmaPreallocatedDictionary.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The right way to use Magma is to do things as object-oriented as<br>
possible, and only rely on MagmaCollections for applying<br>
value-indexing to the objects. Is documentNumber extrinsic to the<br>
system, or is it a relational pointer to a Document object?<br></blockquote><div><br></div><div>For now, documentNumber is a vi of customer (just aString) but it could be anObject in other iteration. Maybe is a good moment to reify it to a Document object (i need find a good name for this class) with document number and sex variables instance because I need it for the key of MagmaPreallocatedDictionary since document numbers (in Argentine) aren't unique. So, I need document number and sex to find a customer.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Regards,<br>
<font color="#888888"> Chris<br></font></blockquote><div><br></div><div>Thanks,</div><div>Facu </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Thu, Dec 9, 2010 at 5:47 PM, Facundo Vozzi <<a href="mailto:facundov79@gmail.com">facundov79@gmail.com</a>> wrote:<br>
> Now I'm getting a performance problem.<br>
> I'm bulk loading transactions in sets (from a file) of 1250. Each of one has<br>
> references to 3 objects, 3 numbers and 2 dates.<br>
> When I test it without setting the customer it take to me 614 milliseconds<br>
> to create the 1250 instances but if I look up for each client according to<br>
> the client code it take to me 204158 milliseconds (3.40 minutes).<br>
> Customers is a MagmaCollection and this is the method of the message that<br>
> I'm sending 1250 times:<br>
> customerAtDocumentNumber: unString sex: otroString<br>
> "Devuelve un invividuo o una organizacion dependiendo de si unString<br>
> corresponde a un número de documento o a un número de cuit. NOTA: se debe<br>
> tener en cuenta el sexo por existir números de dni repetidos entre varones y<br>
> mujeres."<br>
> | aFewCustomers |<br>
> aFewCustomers := self customers where: [ :each | (each documentNumber =<br>
> unString)].<br>
> ^customers detect: [:each | each documentNumber = unString and: [each sex =<br>
> otroString]] ifNone: []<br>
><br>
><br>
> Customers has an index on documentNumber. Now I go to profile it but I need<br>
> to find how to do it in Pharo.<br>
> I thing that I can switch customers from MagmaCollection to MagmaDictionary<br>
> and set the document number + sex how the key. What do you think?<br>
> See you,<br>
> Facu<br>
><br>
> On Thu, Dec 9, 2010 at 7:36 PM, Facundo Vozzi <<a href="mailto:facundov79@gmail.com">facundov79@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>> If you do a copy, then you will be creating multiple instances of<br>
>>> various "system entities", which I'm guessing don't want to do; you<br>
>>> would rather have just one instance, referenced from multiple<br>
>>> transactions, right?<br>
>><br>
>> Yes, you're right I don't want multiple instances.<br>
>>><br>
>>> So all you need to do is just look-up the *equivalent* Code in session<br>
>>> which is doing the loading. It will be the one identical instance in<br>
>>> the repository.<br>
>><br>
>> Yes, to do that I'm passing the session which is doing the loading by<br>
>> argument. But I think that my error here is that I'm implementing the<br>
>> protocol to get one entitiy instance by code or name on the Entity class<br>
>> side. I think is<br>
>> better implement it, by example #clientOfCode: aCode, in my system<br>
>> instance<br>
>> which is the root of each session. In this manner I don't need pass the<br>
>> user session by argument. I think that my traditional database mapping<br>
>> thinking betrayed me<br>
>>><br>
>>> But yes, this is one of the use-cases for which FP's were invented, it<br>
>>> can be a more elegant solution, especially if the number of Codes is<br>
>>> always changing or increasing. See<br>
>>> MagmaTestCase>>#testForwardingProxy.<br>
>><br>
>> Yes, I will see it right now.<br>
>> Facu<br>
>><br>
>>><br>
>>> - Chris<br>
>>><br>
>>><br>
>>> > Thanks for your help,<br>
>>> > Facu<br>
>>> ><br>
>>> > On Thu, Dec 9, 2010 at 4:35 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> I'm not sure I fully understand the context, but a third option might<br>
>>> >> be to use ForwardingProxies. Especially if the shared objects can be<br>
>>> >> updated by only one session (like a batch updater, for example). Then<br>
>>> >> every other (user client) session will share the same instances in<br>
>>> >> memory.<br>
>>> >><br>
>>> >> HTH,<br>
>>> >> Chris<br>
>>> >><br>
>>> >> On Wed, Dec 8, 2010 at 1:13 PM, Facundo Vozzi <<a href="mailto:facundov79@gmail.com">facundov79@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >> > Hi all,<br>
>>> >> > I'm refactoring my code and I found that I have two ways to do the<br>
>>> >> > same<br>
>>> >> > in<br>
>>> >> > distint parts of my system.<br>
>>> >> > 1) Entity class >> atCode: aCode<br>
>>> >> > "Answer the receiver instance with code equal to aCode or evaluate<br>
>>> >> > aBlock if<br>
>>> >> > it doesn't exists."<br>
>>> >> > ^(self all detect: [:one | one code = aCode]) copy<br>
>>> >> > or<br>
>>> >> > 2) Entity class>> atCode: aCode inSession: anUserSession<br>
>>> >> > "Answer the receiver instance with code equal to aCode or evaluate<br>
>>> >> > aBlock if<br>
>>> >> > it doesn't exists."<br>
>>> >> ><br>
>>> >> > ^(self allInSession: anUserSession) detect: [:one | one code<br>
>>> >> > =<br>
>>> >> > aCode]<br>
>>> >> > The difference is that 1 is using the shared session so I need copy<br>
>>> >> > the<br>
>>> >> > object to be used (referenced by other object) on anUserSession. The<br>
>>> >> > uggly<br>
>>> >> > of 2 is that I have to pass anUserSession as argument.<br>
>>> >> > Either way works well, is really the same?<br>
>>> >> > Thanks in advance,<br>
>>> >> > Facu<br>
>>> >> > (*) I eliminate aBlock for absent elements for this example<br>
>>> >> > _______________________________________________<br>
>>> >> > Magma mailing list<br>
>>> >> > <a href="mailto:Magma@lists.squeakfoundation.org">Magma@lists.squeakfoundation.org</a><br>
>>> >> > <a href="http://lists.squeakfoundation.org/mailman/listinfo/magma" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/magma</a><br>
>>> >> ><br>
>>> >> ><br>
>>> ><br>
>>> ><br>
>><br>
><br>
><br>
</div></div></blockquote></div><br>