[sword-devel] Listkey loop over
Manfred Bergmann
manfred.bergmann at me.com
Fri Feb 26 17:09:48 MST 2010
I did for both cases a loop from gen1 to rev22.
The no persist version took: 4.155s
The persist version: 4.651s
Pretty amazing, I would have though it's the other way around.
Both very fast. On smaller ranges the difference is hardly measurable.
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