[sword-devel] Listkey loop over

Manfred Bergmann manfred.bergmann at me.com
Sat Feb 27 05:20:31 MST 2010


Another difference I experienced is in commentary modules and skipping consecutive links which does only work or is done by default in the persisting key version.
Seems logical because the position change happens in the module and there it can take care of the skipConsecutiveLinks flag.
Is there a way to achieve this also in the none persisting key version?


Manfred


Am 26.02.2010 um 18:18 schrieb Troy A. Griffitts:

> Right, mod++ does call key++. The core difference in the persist case is that the key persists inside the mod such that mod++ is calling yourPersistedKey++. It's like symlinking the mod key to your key. But in the non-persist case there are 2 keys. Your key and the module's internal key. Calling setKey in a non persistent way merely syncs those 2 keys up. It like saying setKey("Gen.1.1"). This merely positions the modules internal key to Gen.1.1.
> 
> As far as speed, the technical details of all this might be trickier than you imagine. A module's own internal key is always the fastest it can work with. Sometimes, if all is perfect (same internal ListKey element type with same v11n), you are correct that the persist method might be slightly faster; otherwise, the same type of translation will need to occur as when you call setKey("Gen.1.1"). 
> 
> Thanks for getting back with me so soon. If you find speed differences contrary to my synopsis above, please let me know. We haven't had an optimization pass for a few revs and you may find some corners we can cut.
> 
> Troy
> 
> 
> 
> Manfred Bergmann <manfred.bergmann at me.com> wrote:
> 
>> Hello Troy.
>> 
>> That helped, yes.
>> 
>> So for the example without a persistent key the iteration is still in the key but the key has to be set to the module each time before the call to RenderText().
>> I thought the use case is the same for both persist and no persist because mod++ actually internally calls key.increment() if I'm not mistaken and also sets error so that key.Error() is reflected by mod.Error().
>> But the two don't seem to be the same.
>> 
>> I would say that the second approach is the more expensive one because the key is copied each time with all it's properties?
>> 
>> 
>> Regards,
>> Manfred
>> 
>> Am 26.02.2010 um 17:13 schrieb Troy A. Griffitts:
>> 
>>> Dear Manfred,  What I think you are getting at, is, given:
>>> 
>>> ListKey verses = VerseKey().ParseVerseList("Gen 1:1;4:5-8");
>>> 
>>> What is the difference between:
>>> 
>>> ----------------------
>>> verses.Persist(true);
>>> mod.setKey(verses);
>>> for (mod == TOP; !mod.Error(); mod++) {
>>> 	cout << mod.RenderText();
>>> }
>>> ======================
>>> for (verses = TOP; !verses.Error(); verses++) {
>>> 	mod.setKey(verses);
>>> 	cout << mod.RenderText();
>>> }
>>> ++++++++++++++++++++++
>>> 
>>> and I think you'll find not too much.  I believe the reason you were seeing undesired results and a slower speed was because in your second example, you were initializing mod to Gen.1.1 and incrementing until you reached Gen.4.8,  Your first example should iterate 5 verses.  Your second example should iterate over a thousand verses.  I believe the two examples I've listed above compare apples to apples when it comes to persistent vs. non-persistent keys, and both should only iterated the 5 verses in your parse string.
>>> 
>>> Hope this helps.
>>> 
>>> Troy
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Manfred Bergmann wrote:
>>>> Hi.
>>>> Again a SWORD API question.
>>>> I'm trying to optimise memory usage and speed issues.
>>>> At the moment I believe the API or better SWModule SWKey usage in MacSword is not as good as it could be.
>>>> Now while improving that I came across one or two questions.
>>>> First the following code (all code is in Objective-C syntax but is almost an equivalent to the C++ API):
>>>> ---------------
>>>> - (void)testLoopWithModulePosWithDiverseReference {
>>>>   SwordListKey *lk = [SwordListKey listKeyWithRef:@"gen 1:1;4:5-8" v11n:[mod versification]];
>>>>   [lk setPersist:YES];
>>>>   [mod setKey:lk];
>>>>   NSString *ref = nil;
>>>>   NSString *rendered = nil;
>>>>   while(![mod error]) {
>>>>       ref = [lk keyText];
>>>>       rendered = [mod renderedText];
>>>>       NSLog(@"%@:%@", ref, rendered);
>>>>       [mod incKeyPosition];
>>>>   }
>>>> }
>>>> ---------------
>>>> This code works and is pretty fast.
>>>> The output are only verses as in the reference. That's how it should be. The module only keeps a reference to the key.
>>>> This example:
>>>> ---------------
>>>> - (void)testLoopWithModulePosNoPersistWithDiverseReference {
>>>>   SwordListKey *lk = [SwordListKey listKeyWithRef:@"gen 1:1;4:5-8" v11n:[mod versification]];
>>>>   [lk setPosition:BOTTOM];
>>>>   SwordVerseKey *bot = [SwordVerseKey verseKeyWithRef:[lk keyText] v11n:[mod versification]];
>>>>   [lk setPosition:TOP];
>>>>   [lk setPersist:NO];
>>>>   [mod setKey:lk];
>>>>   NSString *ref = nil;
>>>>   NSString *rendered = nil;
>>>>   while(![mod error] && ([(SwordVerseKey *)[mod getKey] index] <= [bot index])) {
>>>>       ref = [[mod getKey] keyText];
>>>>       rendered = [mod renderedText];
>>>>       NSLog(@"%@:%@", ref, rendered);
>>>>       [mod incKeyPosition];
>>>>   }
>>>> }
>>>> ---------------
>>>> This version however renders all verses from gen 1:1 to gen 4:8.
>>>> The only difference is that the module keeps it's own copy of the key.
>>>> The boundary check "![mod error]" doesn't work here so I added the index check mainly because I didn't know otherwise.
>>>> How does this loop work with a none persistent key?
>>>> Thanks,
>>>> Manfred
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above 
>>> 
>>> 
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>> 
>> 
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page




More information about the sword-devel mailing list