Thanks for sharing the stats! Looks like a great improvement!
I'm fine with this going in sans flag if we test it bit more first.
Have your tried it with the --browserify flag?
On Apr 20, 2016 7:18 AM, "Victor Sosa" <sosah.vic...@gmail.com> wrote:
> This is an amazing improvement in Cordova performance. Thanks Jason
> +1!!
>
> On Wed, Apr 20, 2016 at 9:14 AM Shazron <shaz...@gmail.com> wrote:
>
> > +1 what Jesse said
> >
> > On Tuesday, April 19, 2016, Jesse <purplecabb...@gmail.com> wrote:
> >
> > > This sounds great!
> > > Personally, I don't think this belongs behind a flag, why would anyone
> > not
> > > want to build faster?
> > > I think we just need to test more to make sure it functions as expected
> > > everywhere, and then it should just make it's way in directly, without
> > the
> > > overhead of addition flag code, or documentation ...
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > > On Tue, Apr 19, 2016 at 5:58 PM, Jason Ginchereau <
> > jason...@microsoft.com
> > > <javascript:;>>
> > > wrote:
> > >
> > > > I collected data for 4 projects with varying numbers and sizes of
> > source
> > > > files (mostly .js and .png):
> > > > Tiny : 17 files, 0.24 MB (A new Cordova project created from
> > the
> > > > VS template)
> > > > Small : 55 files, 7.7 MB
> > > > Medium: 242 files, 44 MB
> > > > Large : 12,923 files, 134 MB
> > > >
> > > > Following are full -> incremental times for 'cordova prepare android'
> > > > commands, without any source file changes in between, averaged over 5
> > > warm
> > > > runs on my medium-spec Windows desktop machine with SSD:
> > > >
> > > > Tiny : 1.98 -> 1.84 s
> > > > Small : 2.40 -> 1.94 s
> > > > Medium: 4.22 -> 2.02 s
> > > > Large : 50.24 -> 5.81 s
> > > >
> > > > As you can see, larger projects see greatly improved prepare times
> when
> > > > using the incremental option.
> > > >
> > > > Also, I confirmed that without using the --incremental option with
> this
> > > > change, times are not measurably different compared to the released
> > > version
> > > > 6.1.1 of Cordova. So there doesn't seem to be any regression compared
> > to
> > > > the previous use of shelljs.cp('-R') to blindly copy files when
> > > preparing.
> > > >
> > > > Jason
> > > >
> > > > -----Original Message-----
> > > > From: Steven Gill [mailto:stevengil...@gmail.com <javascript:;>]
> > > > Sent: Tuesday, April 19, 2016 3:14 PM
> > > > To: dev@cordova.apache.org <javascript:;>
> > > > Subject: Re: [DISCUSS] Faster incremental builds
> > > >
> > > > Sounds like a worthy cause. Do you have any stats on how much time is
> > > > saved?
> > > >
> > > > Definitely put it behind the --incremental flag to start.
> > > >
> > > > On Tue, Apr 19, 2016 at 2:43 PM, Jason Ginchereau <
> > > jason...@microsoft.com <javascript:;>>
> > > > wrote:
> > > >
> > > > > We've had a few customers complain that the dev inner loop for
> > Cordova
> > > > > apps is slow compared to native app development. So recently I've
> > been
> > > > > looking at ways to optimize it. The two largest pieces of a Cordova
> > > > > build are "prepare" and "compile" phases. While there's not much we
> > > > > can realistically do to speed up the native-code compilation (in
> > which
> > > > > gradle/xcodebuild/etc is invoked), it's clear that the prepare
> phase
> > > > > is not nearly as efficient as it could be. So I opened a JIRA for
> > > > > that, and I have a solution in the works that I want to get
> feedback
> > > on.
> > > > >
> > > > > CB-11117: Preparing platforms should skip copying files which
> haven't
> > > > > changed<
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f
> > > > > %2fissues.apache.org
> > %2fjira%2fbrowse%2fCB-11117&data=01%7c01%7cjasongi
> > > > > n%40microsoft.com
> > %7c297f714a60a94c3f258108d3689ff306%7c72f988bf86f141a
> > > > >
> > f91ab2d7cd011db47%7c1&sdata=E2Ww9LusEmVkUgjXPPGnxcGz%2fMH8fWruqGWUrLXq
> > > > > KRk%3d> Many cordova CLI commands include a "prepare" operation,
> > > > > including 'cordova build', 'cordova run', 'cordova plugin add', and
> > > > > more. Every time each of those commands runs, the target platform
> is
> > > > > "prepared", which involves copying all files from [<project>/www,
> > > > > <project>/platforms/<platform>/platform_www,
> > > > > <project>/merges/<platform>] to the platform's target www folder,
> as
> > > > > well as copying a bunch of icons and splash screens to
> > > platform-specific
> > > > locations.
> > > > >
> > > > > For the very first prepare of a platform, all that file copying is
> > > > > necessary. But most of the time after that most of the files being
> > > > > copied have not changed and therefore don't really need to be
> copied
> > > > > again. So the typical developer inner loop (edit a few source
> files,
> > > > > build and run the app, repeat) is a lot slower than it could be
> for a
> > > > > Cordova project, especially one that includes a significant number
> of
> > > > > source files or resources.
> > > > >
> > > > > Instead, Cordova should be smart enough to skip copying of files
> that
> > > > > haven't changed, based on their last-modified timestamp. But there
> > > > > should still be a way to force a clean/full/non-incremental copy if
> > > > > desired. To preserve compatibility with all possible existing
> > > > > workflows, I'm leaning toward keeping the full copy as the default
> > > > > behavior, and enabling the optimization only with a new
> --incremental
> > > > > flag, at least initially. If we find the incremental option is
> > working
> > > > > well for everyone, we can promote that behavior to default in a
> > future
> > > > major version update.
> > > > >
> > > > > See PRs here for implementation of this idea...
> > > > > https://github.com/apache/cordova-lib/pull/429: Add FileUpdater
> > module
> > > > > to cordova-common
> > > > > https://github.com/apache/cordova-android/pull/295: Use
> FileUpdater
> > to
> > > > > optimize prepare for android platform I'll submit PRs for
> cordova-ios
> > > > > and cordova-windows platforms soon, as well as a cordova-cli change
> > to
> > > > > enable the optimization via a new --incremental flag (assuming we
> > > > > don't want to make it the default behavior).
> > > > >
> > > > > Jason
> > > > >
> > > > >
> > > >
> > >
> >
>
