Look what they've done to my 'go card' 5.0.2

[pderks]

Hello,

in October 2011 I made a data stack which today has 6213 cards. Card 1 has a 'Find' button and a 'Found' field. My Find script checks all cards (go card) and returns a list with 80 characters containing the searched string, the card number, the foundChunk.

Today's multiple test confirm: each find process needs averagely in
LC 5.0 : 20 secs,
LC 5.0.2: 210 secs (10 times slower)

Another test with this script

on BrowseAllCards
repeat with ii = 1 to the number of cards
go card ii
wait 1 ticks
end repeat
end BrowseAllCards

LC 5.0 : 203 secs,
LC 5.0.2: 362 secs (an increase of nearly 80 %).

I use the Mac version of LiveCode.
Has anyone same | similar experience ?

Peter

[Klaus]

Hi Peter,

I have no idea why LiveCode is that slow in the current version!

But since it sounds that you only ant to search all cards (instead of looking at them)
why not LOCK the screen, which will speed up thing HEAVILY!?

I am sure this will take just ca. (number of cards) ticks, although it does not make much sense

Code: Select all

on BrowseAllCards
  lock screen
  repeat with ii = 1 to the number of cards
    go card ii
    wait 1 ticks
  end repeat
  unlock screen
end BrowseAllCards

So add a "lock screen" to your "search" script and it might even get faster that in version 5.0


Gruß aus Hennef

Klaus

[pderks]

Hi, Klaus,

a lot of your posts contain valuable hints, but this one - it's not your fault – is an exception. For my 6213 cards your script needed 323 seconds (my script took 362 (5.0.2) resp. 203 secs (5.0)).

By the way: the intention of my 'BrowseAllCards' is to present to the forum a script for a reproducible performance test of 5.0 vs 5.0.2.

My real problem is the difference between 20 and 210 secs in my UseList database I use repeatedly.

Nevertheless: thank you …

Grüsse vom Niederrhein

Peter

[Klaus]

Hi Peter,

ah, ok, hmmm...

Do you have pre-/opencard etc. scripts in that stack?


Best

Klaus

[jacque]

Test also with messages locked. That makes a big difference. Version 5.02 introduced some new features that may be slowing down the message path. Locking messages will tell you if this is the cause.

The search handler could be much faster by using the native "find" command without going to each card. The original script has an embedded wait time of almost 104 seconds (one tick per card) which isn't really necessary and which will continue to grow as the stack gets larger.

[FourthWorld]

For anything about ~5000 cards I would consider a different data store, such as a delimited text file, XML file, stack properties, or sqLite.

[pderks]

Hi,

thanks for your answers up to now.

@ Klaus:
there is one 'OpenStack', zero 'OpenCard' handlers.

@ Jaqueline:
1)
lock screen
lock messages
lock recent
are of course built into all my stack browsing routines.
2)
"Version 5.02 introduced some new features that may be slowing down the message path."
Acknowledged, but that does not justify the said enorme speed differences (see the table below).
3)
"The search handler could be much faster by using the native "find" command without going to each card."
The native 'Find' command does not return the list of clickable lines I need: 80 characters text with embedded search string, CardNumber, FoundChunk.

@ Richard:
your proposal is not an option for me – sorry.
I have own selfmade HyperCard stacks which have collated up to more than 30 000 cards with text fields, some list fields, 3 b/w pictures per card. I experienced sufficient browsing with HyperCard 2.4.1 and Mac OS 9.2.2 resp. Classic under Mac OS X 10.4.

Here my actually measured values returned by my trivial "BrowseAllCards" script:
application system computer cards secs cds/sec sec/cd
HyperCard 4.2.1 OS 9.2.2 PMac G4 1.25 20804 620 33.6 0.03
LiveCode 5.0 OSX 10.7.2 Mac Pro 2.8 6213 203 30.6 0.03
LiveCode 5.0.2 OSX 10.7.2 Mac Pro 2.8 6213 362 17.2 0.06

I think I have to emphasize, that "BrowseAllCards" is a test to validate the bad results returned from my individual 'Find' script in my "Real-World-Stack" containing the UseList data.

Until now LiveCode imposed by its unlimited field capacity (my max. 50.000.000 chars) and its (browsing) speed. I consider the downgrade to version 5.0

Peter

[FourthWorld]

@ Richard:
your proposal is not an option for me – sorry.
I have own selfmade HyperCard stacks which have collated up to more than 30 000 cards with text fields, some list fields, 3 b/w pictures per card. I experienced sufficient browsing with HyperCard 2.4.1 and Mac OS 9.2.2 resp. Classic under Mac OS X 10.4.

HyperCard and LiveCode are designed very differently with regard to how card records are stored and unpacked. HC paged from disk, so although Atkinson himself said it wasn't a database it held up reasonably well when used as such as long as one compacts regularly. But LiveCode reads everything in a stack file into memory whenever a stack is loaded, which gives it some advantages with stacks of a certain size but beyond that you'll start to see some serious performance issues, esp. with saving since it has to do a backup, write the file, do an integrity check, and then delete the original when saving.

As long as it's working for you there may be no need to change. But if it starts giving you trouble, we can help you come up with simple solutions to migrate the data to more optimal stores.

[pderks]

Hi,

Klaus gave the decisive hint:

But since it sounds that you only ant to search all cards (instead of looking at them)
why not LOCK the screen, which will speed up thing HEAVILY!?

Now I "look" into the data field of each card without going to it, et voilà … speed is back: now searching & reporting takes averagely 9 seconds (!) independent of the number of finds (3 or 2700) …

Thank you all, especially Klaus

Peter

[Klaus]

Hi Peter,

glad I could help!
Macht dann fünf Mark!


Best

Klaus