ID caching: how to test?

[Peter Haworth]

That case could make a difference yes, but it's hard to imagine a custom
control with that number of components.  Datagrids do chew up a lot of
controls, it's true but it's usually in the hundreds because they only
create controls for the number of rows visible in the datagrid, not the
total rows of data.

The script you provided seems to imply that only the last id referenced is
cached and as soon as you reference another id, the caching of the first
one is lost. Am I understanding that right?  If so, I find this caching of
even less value.  (OK, just saw your latest post and now know it's not
limited to the last referenced control - that's good because I think it
would have been pretty useless only caching one control!)

Anyway, I'm sure there are circumstances where this change would provide a
significant performance improvement.  I just think they are few and far
between and would much rather see RunRev spend their time, no matter how
little, on fixing <insert your favorite bug number here>.  I've seen so
many software projects get delayed by sneaking in random features like this
- it's not just the time it takes to code them, it's the time to do the
various levels of testing, documentation, etc as well.

All the above IMHO :-)



Pete
lcSQL Software <http://www.lcsql.com>


On Sun, May 12, 2013 at 4:26 PM, Alex Tweedly <alex at tweedly.net> wrote:

> Does it matter ? Not sure, but let me try to construct a case ...
>
> 1. Custom Controls are going to be more common / important
>
> 2. Some custom controls (e.g. datagrids) will dramatically increase the
> number of controls frequently encountered on a card.
>     (My simple test only used 1000 controls - make that 20 or 50K controls
> and the times might be more noticeable).
>
> 3. It is common to do a number of accesses to the most recently created
> controls (i.e. those for which linear searching was most costly).
>
> 4. Some custom controls might need to do this pretty quickly (e.g.
> scrolling a datagrid ??? or something like that - maybe).
>
> 5. (I could be totally wrong here ...)
>     It's probably a 5-lines of code change.
>
> local sLastIdSearched, sLastIDValueReturned
>
> function revFindByID pID
>    if pID = sLastIdSearched then return sLastIDValueReturned
>    .....
>    put pID into sLastIdSearched
>    put tValue into sLastIDValueReturned
>    return tValue
> end revFindByID
>
> (translation into C++ left as an exercise :-)
>
> -- Alex.
>
>
> On 12/05/2013 20:08, Peter Haworth wrote:
>
>>
>> My question is does it really matter? If my math is correct, you'd have to
>> do 50,000 accesses to get to a 1 second difference in performance based on
>> the 250ms/5ms times, which is still barely noticeable to most users.
>>
>> Personally, I think there are more important things for RunRev to address
>> than this.  I feel the same way about the new button that displays the
>> script line that caused a message to appear in the message box;  I can't
>> imagine ever using that feature.
>>
>> Pete
>> lcSQL Software <http://www.lcsql.com>
>> ______________________________**_________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>>
>
>
> ______________________________**_________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>