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 <[email protected]> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
