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.bergm...@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@crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above
>>>
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel@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@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
