Closed GoogleCodeExporter closed 9 years ago
Apology.. I'm missing this call on WroConfigurationPropertlyLoader:
config.setResourceWatcherUpdatePeriod(valueAsLong(sourceProperties.get(ConfigConstants.resourceWatcherUpdatePeriod.name()), 0));
Original comment by AlexWib...@gmail.com
on 4 Sep 2013 at 1:22
Have you tried upgrading to a newer version? The latest release is 1.7.0.
Original comment by alex.obj...@gmail.com
on 4 Sep 2013 at 5:22
Hi,
Sort of. I checked out the 1.7.1-SNAPSHOT (assuming that if the parallel thing
was fixed in 1.7.0, it should have been fixed in 1.7.1-SNAPSHOT too). But I got
the same result. The resources were not processed in a Callable.
I also notice that jshint is running much much slower. In 1.4.7 without
parallelization, jshint completes in about 60 secs. In 1.7.1-SNAPSHOT it
completes in ~ 4 minutes.
Original comment by AlexWib...@gmail.com
on 4 Sep 2013 at 6:02
Could you share the project you are using for benchmarking? I would like to run
it locally with newer and older version. The slowness of 1.7.1-SNAPSHOT can be
explained by usage of a newer version of jshint, but it shouldn't be 4 times
slower...
Original comment by alex.obj...@gmail.com
on 4 Sep 2013 at 7:00
Hmmm.... it would be a little bit hard, as the project is for a client, and I
dont think they will be happy if I put it here. But to give an idea, there are
410 resources to be processed.
I will try to switch to some other version (between 1.4.7 - 1.7.1-SNAPSHOT),
and see at which point the problem starts to occur. Nevertheless, the parallel
thingy doesnt work in 1.7.1-SNAPSHOT, and the patch file above seems to fix it.
Original comment by AlexWib...@gmail.com
on 4 Sep 2013 at 7:04
I don't need necessarily your client application javascript resources. Having a
sample project, containing the same amount of javascript, would be useful to
perform a benchmark. You can easily replace javascripts you don't want to share
with something open source....
Original comment by alex.obj...@gmail.com
on 4 Sep 2013 at 7:07
Hi,
Here is a sample project. You can compare v 1.4.7 against 1.7.0
On my computer, running mvn clean test on 1.4.7 takes about 57 secs. Running
the same goal on 1.7.0 takes about 2.5 mins.
Original comment by AlexWib...@gmail.com
on 4 Sep 2013 at 1:02
Attachments:
Indeed, the jshint plugin is running faster with 1.4.7 version when comparing
to 1.7.0.
I will do some profiling to understand what makes it slower.
Original comment by alex.obj...@gmail.com
on 4 Sep 2013 at 3:16
Cool. Thanks a lot for that. There is still an issue with running jshint in
parallel though.
Original comment by AlexWib...@gmail.com
on 4 Sep 2013 at 11:35
Sample project.
Original comment by AlexWib...@gmail.com
on 4 Sep 2013 at 11:56
Attachments:
It is already fixed in the banch called issue782.
Original comment by alex.obj...@gmail.com
on 5 Sep 2013 at 5:26
An update regarding jshint performance issue with 1.7.0:
The wro4j 1.7.0 uses jshint-2.1.3 (loaded from a webjar), while earlier
versions of wro4j uses a much older jshint (prior to 2.0.0 release). Apparently
the newer version of jshint are slower (probably because more complex static
code analysis is being performed in newer version) comparing to older one.
To prove that, I have changed the jshint webjar version from 2.1.3 (latest) to
12 (older) and noticed that for the same project, processing was about ~2 times
faster.
Original comment by alex.obj...@gmail.com
on 5 Sep 2013 at 1:34
One more aspect related to newer versions of jshint (post 2.0.0): these are
using AMD with require.js. Though I'm not sure, I suspect that this has also an
impact on performance. Unfortunately, I don't have tools which would help me to
profile the javascript code performance and I believe this should be handled by
jshint project (assuming they are aware about this problem).
Original comment by alex.obj...@gmail.com
on 5 Sep 2013 at 1:39
One more update:
I did a benchmark and noticed the following:
linting the same javascript with older version of jshint take about 160ms,
while with jshint-2.1.3 it takes ~400ms..
That explains why processing of 180 resources is 2.5x slower with wro4j-1.7.0.
The good news is that you'll be able to run the pre processors (and all groups)
in parallel starting with next release.
Original comment by alex.obj...@gmail.com
on 6 Sep 2013 at 9:41
Fixed parallelPreprocessing issue in branch 1.7.x
Original comment by alex.obj...@gmail.com
on 6 Sep 2013 at 3:06
Original comment by alex.obj...@gmail.com
on 6 Sep 2013 at 3:07
Original issue reported on code.google.com by
AlexWib...@gmail.com
on 4 Sep 2013 at 12:24Attachments: