This looks very useful .
I think we need to wait until HQ weighs in on my bug report. Regardless of the
fact that it works on iOS and Oreo, one has to wonder how on earth we can close
a stack which is set to destroy on close, turn acceleratedRendering to false
(assume previously cached controls are cleared); open a new stack and *still*
see the old stack behind the new, one, as if they two are still fighting for
the pixel map…. even if the old one "loses" on iOS and Oreo…and the new stack
"wins" the display.. .the old one could still be in the heap.
So if this indicates a failure at garbage collection (my very un-informed
guess) the app will run out of RAM very fast. So however hard we work to
optimize any script…it will get us nothing, 5 minutes into using the app,
moving from stack to stack, crash is imminent.
That said the new script profiler in 9 is awesome (when it runs…often I start
it, stop it and it is empty…)
e.g. I found a repeat loop that keeps setting the left of a large parent group
being build up from copying child groups run time…everytime a child group is
added (100 times) and this one task of setting the left of group "item-list" to
0 on every loop, even with lockscreen on, was taking 80% of the time needed to
do the job. it was this developer's (not me) attempt to overcome the challenge
issue of the coords/ ect of the group constantly being lost despite use of
on layoutGroup pNum
-- general list group stuff
set the lockupdates of group "item list" to true
set the lockupdates of me to true
the coords still keep getting lost…and require resetting the parent group so
that 0,0, us actually "known" to the subgroup being appended as a "row" at the
bottom.
Me thinks we are working too hard at this one… and I'm noodling a refactor… it
will be interesting if DataGrid2 represents a "leap" forward for this kind of
graphically complex list group. I have stayed away from it as more complex
than needed… OTOH if DataGrid2 will be more performant, then we should use it.
Meanwhile, other operations, like fetch data from the database, setting props
on the next-copied subgroup etc. which I thought (wrongly) would be costly
were all profiling in at 1 millisecond.. So this new tool is going to be really
helpful … I just have to figure out why it so often appear blank after running
scripts.
Richard Gaskin wrote:
While looking for one of the URLs I included in my last post, I came
across this:
How we reduced our Android app’s memory footprint by 50%
<https://medium.freecodecamp.org/how-we-reduced-memory-footprint-by-50-in-our-android-app-49efa5c93ad8>
I have no idea if those strategies would make sense in LC's internals,
or whether LC is already doing some of that sort of bitmap reuse. But
an interesting read just the same.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
