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

[Tiemo Hollmann TB]

I made some more performance benchmarks with my real life data
I deactivated my "special sort" xSortListe handler and replaced it just by: 
1. sort lines of tListe numeric
2. sort lines of tListe international
(though it is not a solution for my sorting feature, but just to drill it down)

LC 6.5.2, average times:
My repeat loop: 14 millisecs
plain Sort numeric: 3 millisecs
plain Sort international: 128 millisecs

LC 7.0.5, average times:
My repeat loop: 55 millisecs (+393%)
plain Sort numeric: 8 millisecs (+267%)
plain Sort international: 4100 millisecs (+3203%)

for my real life app just unacceptable
Tiemo



-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] Im Auftrag von Tiemo Hollmann TB
Gesendet: Samstag, 30. Mai 2015 18:59
An: 'How to use LiveCode'
Betreff: AW: AW: How do you handle the poor performance of LC 7? 

Hi Malte, you and Richard are on the right trace - and I was blind :) The time cruncher is not the repeat loop, but my "special" sorting routine. I have a mixed alpha-numerical list. It is perhaps a little bit strange, but I want the numbers to be sorted at the end of the list. "A-Z-1-9-10-99-100-x" Because I didn't found a "build-in" function to realize this, that’s why I created this "Tiemo-Sort" (xSortListe). Perhaps there is a much straight forward way to do this. Because I never had performance issues with this I completely forgot this handler, I think I have to rethink this special sort:


---------------------------------------
function xSortListe pListe
   -------------------------------------
   -- Sortierung einer einfachen Liste, Zahlen am Ende
   local tZeile, tLine, tArt, tOben, tAlphaSort
   sort lines of pListe numeric -- gesamte Liste numerisch sortieren, damit stehen alle Alphazeilen vorne und numerische hinten, Zahlen in richtiger Folge.
   put the number of lines of pListe into tOben
   
   put "mixed" into tArt
   if not isNumber(first char of line tOben of pListe) then -- Letztes Zeichen ist ein Alpha, also ganze Liste Alpha
      put "alpha" into tArt
   else if isNumber(first char of line 1 of pListe) then -- Letztes Zeichen ist Zahl und 1. Zeichen auch Zahl
      put "numeric" into tArt
   end if
   switch tArt
      case "alpha" -- reine Alphaliste einfach international sortieren
         sort lines of pListe international
         break
      case "mixed" -- bei gemischter Alpha + Zahlenliste nur den Alphateil international sortieren
         put 1 into tZeile
         repeat for each line tLine in pListe
            if the first character of tLine is a number then -- erste Zeile, die mit einer Zahl beginnt
               exit repeat
            end if
            add 1 to tZeile
         end repeat
         put line 1 to (tZeile - 1) of pListe into tAlphaSort -- den Alpha-Teil herausnehmen und international sortieren
         sort lines of tAlphaSort international
         put tAlphaSort into line 1 to (tZeile - 1) of pListe -- den Alphateil wieder zurück in die Gesamtliste setzen.
         break
         -- rein numerische Liste ist am Anfang schon sortiert
   end switch
   return pListe
end xSortListe

-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] Im Auftrag von Malte Brill
Gesendet: Samstag, 30. Mai 2015 15:51
An: use-livecode at lists.runrev.com
Betreff: Re: AW: How do you handle the poor performance of LC 7? 

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


_______________________________________________
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