Speed of LCB

[Kevin Miller]

Measuring speed in the context of LCB is a bit different to measuring the
speed in LiveCode script.

If you are calling a lower level library then the speed of LCB is almost
irrelevant as the lower level code will be doing heavy lifting fully
compiled.

When it comes to things like the speed of rendering objects, there are so
many advantages to the way that LCB does it - e.g. the widgets written to
paint just the viewable area (the early prototype list example we did had
10K elements and scrolled smoothly on the very lowest end devices) that I
doubt the speed of execution comes into play.

Where it does matter a bit more are for things like JSON processing. That
said lets see if even as it stands it is an issue for the main use cases
of that library. If it is, it is a new language and there is a great deal
of optimization that we can and will do over time.

And in answer to the machine code compilation question, yes we designed it
like that from the outset so one day in the future that is a possibility!

Kind regards,

Kevin

Kevin Miller ~ kevin at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps




On 10/05/2016, 16:58, "use-livecode on behalf of Richard Gaskin"
<use-livecode-bounces at lists.runrev.com on behalf of
ambassador at fourthworld.com> wrote:

>David Bovill wrote:
>
> > Richard mentioned that LCB can be / is magnitudes slower than Livecode
> > script for certain tasks?
>
>I don't believe I have sufficient data to have made such a specific
>claim.  If I did I was mistaken, as I've not seen enough scripts
>offering equivalent functionality written in both LC Script and LC
>Builder to have been able to provide guidance that precise.
>
>A few weeks ago I did reply to Monte's question here about whether to
>write a library in Script or Builder, and I noted that if the primary
>consideration were execution speed (development speed had already been
>addressed) LC Script would seem the favorable choice.
>
>This was based on two pieces of anecdotal information, one of which I've
>learned is questionable in terms of direct comparison:
>
>- "LiveCode Builder performance improvements" is in the "Planned"
>    section of the Roadmap, a good place for it given that Builder
>    just premiered in v8 and there's the old adage about premature
>    optimization.
>
>- I had run one test in a field validation library which is available
>   as both LC Builder and LC Script:
>   <http://forums.livecode.com/viewtopic.php?f=16&t=26653>
>
>I was discussing the latter with Peter recently and he reminded me that
>LC Builder doesn't yet have regex support.  So while some chunk
>expressions in LC Script outperform some regex operations, in that case
>it seems likely that regex may play a strong role in the measurable
>performance benefit of LC Script in the one function I benchmarked from
>that library.
>
>So until someone writes a set of tests that are truly equivalent in LS
>Script and LC Builder, any performance benefit one way or another is
>unknowable.
>
>Since optimization of LC Builder is already on the Roadmap, and the need
>for optimization of LC Script is both more pervasive in terms of
>affected users and well known by the team, for myself I'd wait until
>both optimization efforts are completed before spending too much time
>with benchmark comparisons between them.
>
>That said, if someone has an immediate need for such a comparison I'd be
>curious to see the scripts and the results.
>
>
> > Perhaps it's time to look at a speed comparison between various ways
> > to encode and decode JSON in Livecode.
>
>Neither LC Script nor LC Builder will likely outperform the C++ used in
>available JavaScript engines.
>
>Ideally that optimized code in machine-compiled form would become
>available to us, both for rebustness and performance as JSON's role in
>daily work continues to expand.
>
>I would imagine Monte's external will outperform any scripted
>implementation.
>
>
> > I thought jsonImport would wrap a C library - but looking at the code
> > on GitHub
> > 
><https://github.com/livecode/livecode/blob/develop/extensions/libraries/js
>on/json.lcb>it's
> > all native LCB I think. That would make no sense if LCB was slow?
>
>My (likely naive) hope is that LC Builder's tighter internal structure
>will one day lend itself to becoming machine compilable.  I can dream,
>can't I? :)
>
>
> > Does anyone have a speed testing app / framework - in the spirit of
> > open source I'd rather not keep rollin my own :)
>
>I do a lot of benchmarking, but my needs are modest so I have no
>framework per se beyond a simple script I reuse, similar to the variant
>in this post:
>
>Project: Performance Benchmarking Toolkit
><http://forums.livecode.com/viewtopic.php?f=67&t=22072&hilit=benchmark#p11
>3636>
>
>In fact, Malte's thread there may be a good place to continue the
>discussion toward a common, more generalized benchmarking framework.
>
>-- 
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
>
>_______________________________________________
>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