Richard, I’m wondering if the standalone engine size is a concern for anyone else. I have a standalone for iOS that is 3 times smaller when built with 6 over 7. I think I understand that the unicode dictionary is responsible, but until there is a way to selectively remove that, I would rather have the smaller footprint.
Eric On Feb 26, 2015, at 12:45 PM, Richard Gaskin <ambassa...@fourthworld.com> wrote: > The road to enhanced support for Cocoa, Unicode, GTK, iOS, and all the other > things that make up v7 has been a long one, and while it's not been without > difficulty this third point release seems very promising. > > But don't take my word for it. I'm just a fanboy - you can safely ignore > anything I write. :) > > Instead, enjoy this post I came across in the forums today for a fresh take > on v7 - excerpt: > > So I got to try out LiveCode 7.0.3 today and I have to say I > am impressed, the engine is the fastest I've used since the > open source revamp began > <http://forums.livecode.com/viewtopic.php?f=66&t=23387> > > His post is well worth reading, and in my thank you reply I also included > some details about that performance boost in 7.0.3 and an earlier change with > copy-on-write-only which may be of interest to those who've seen performance > issues in the past. > > > Looking ahead: > > Right now RunRev maintains three versions, 6.x, 7.x, and 8.x. This is of > course more expensive than maintaining two, so it's in everyone's interest to > see a productive migration to v7 ASAP so we can have the team focusing on the > things we truly need rather than just patching the past. > > "Version 6, we loved ya', but we gotta move on to the present." > > But of course this needs to be truly productive, and that's where you come in. > > In the past we've discussed isolated benchmarks, but as Peter Brett explained > here a few weeks ago, and Ben explained to me in more detail in our last > meeting, the changes in v7's core are so deep and pervasive that isolated > benchmarks are far less useful than we might think. > > In some areas, given the larger amount of data and automatic encoding > detection for Unicode, we know some aspects of v7 will be slower. > > But in many other areas, with copy-on-write-only and other algorithmic > changes under the hood, many other areas have become much faster. > > So the real focus now is two-fold: > > #1 Priority: Bugs > ----------------- > If you're seeing a bug in v7.0.3 that you do not see in v6.7.3, please report > it ASAP. > > Of course data-loss bugs will get priority, and bugs for which simple > workarounds exist may get a lower priority. But let's do make sure we > catalog any issues unique to v7 so we can all move forward with confidence. > > > #2 Priority: Performance > ------------------------ > Given the holistic nature of the changes in v7, the key here is to find > applications that are noticeably slower. If you have one, send it to support > AT runrev.com with a note explaining where the performance difference can be > found. > > No need to worry about trade secrets and all that: RunRev regularly works > with very sensitive projects, and discards everything noted as such as soon > as their analysis is complete. > > The main thing is that they see it, so if you see a noticeable performance > loss and are concerned about sensitivity of the materials, please at least > write to them describing the issue and your concerns and let's find a way to > take care of it. > > > I write this as an ardent fan of v6.7.x. It's been good to me, and it's > enjoyed a favored position in my Mac's Dock and my Ubuntu Launcher. > > But as of today I'm migrating all new work to v7. I want 2D physics, GPU > rendering, stack views, and more, and those only take longer as long as the > core team is saddled with v6.x backports. > > And for us Linux fanboys, much the enhanced GTK support we crave is already > in v7 (thanks, Fraser!). > > If you have any other concerns about migrating your work to v7, let me know. > Probably best to discuss them here so we can all benefit, but if it's a > sensitive issue you can send me an email if you prefer and I'll do my best to > reply quickly. > > -- > Richard Gaskin > LiveCode Community Manager > rich...@livecode.org > > _______________________________________________ > 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 _______________________________________________ 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
