AW: How do you handle the poor performance of LC 7?

[Mike Bonner]

Malte, it might help if you don't sort the keys on each keystroke, instead
put the keys into a list and sort them once, then keep referring to that
same list as you do your filtering. Its faster to pop the full sorted list
into a working variable on each keystroke and filter than it is to get the
keys, sort the keys, then filter.


To optimize further, you can do a comparison on each keystroke by keeping
track of the previous search.

if char 1 to -2 of the current search string is the same as the previous
search string,.  you've just added a single char to the end of the search
string.  In this case you can do your filter on the most recently filtered
list rather than doing the full list filter each time. Otherwise, pull in
the full sorted list from wherever you're hiding it and do the filter on
that.

On Sat, May 30, 2015 at 7:50 AM, Malte Brill <revolution at derbrill.de> wrote:

> Hey Tiemo,
>
> what does the xSortListe function do? What is rather funny that my real
> life problem childs are also revolving around a live search feature. It
> might well be that your speed issues (as mine) are related to the sorting
> part (if you do a sort). My approach is a little diffrent than yours, as I
> do have numeric keys in the array (and as numeric keys are not in stable
> order in an array I have (had) to sort those on each keystroke).
>
> To be fair towards 7, I have refactored quite a bit of my own code over
> the past weeks and now have scenarios where the performance impact is far
> less dramatic than it used to be. I just got around to test this yesterday
> and now see a speed loss of the 7 engine of 7 to 15% which is somewhat
> acceptable (not good, but acceptable). I had to jump through quite some
> hoops to get there though. The only upside is that stuff got significantly
> faster also in 6.7 so my users would see a general performance boost
> regardless the engine. That is something I can sell. This is speaking for
> my own software though. If I am in control of the budget all it costs is my
> time to refactor existing stuff and most of the times refactoring is my
> friend, as generally the code base gets better. If I am on the other side
> of my programming life, namely coding for other customers, it gets a lot
> harder to sell them on refactoring a couple of 100 stacks, just to get them
> to the same speed with the newer engine, without (many) other benefits. ROI
> isn’t that appealing / existent for them there.
>
> That said, I guess we need more real life things where the 7 and 8 engine
> is slower to hand over to the team, so many thanks you sent your stacks. As
> Mark said, the „laboratory“ benchmark tests do not appear to help as much
> as I would have thought in the first place. On the other hand it is rather
> difficult to send over complete projects if they require additional
> requisites (like a Database, or even worse a complete server) to
> demonstrate the issues. I must say the team has been most helpful there, so
> I really hope for the best.
>
> Cheers,
>
> Malte
>
>
>
> _______________________________________________
> 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