- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
the art of doing nothing
Mon, 2011-09-12, 22:07
#2
Re: the art of doing nothing
On 9/12/11, Paul Phillips wrote:
> Presently the time to do nothing in the scala build is around 30
> seconds. By "nothing" I mean
>
> % sbt package
> % sbt package # time elapsed of this one
>
> It takes ant 2 seconds to do nothing. I know ant is optimized for
> that, but I'd still love to be less than 15x slower.
>
> Note to josh and mark: I realize that in the following, and in any
> other emails I'll write on this subject, the responsibility is split
> in unequal portions between sbt, the scala compiler, the scala sbt
> build, and god knows what else. Unless I explicitly point an
> accusatory finger, I'm only attempting to bring light into the
> darkness. I count on the oracles, scribes, and alchemists to use that
> light to determine who must be sacrificed so that next year's crops
> are bountiful.
>
> Here is one look at what's happening during those 26 seconds.
There are a couple things in the output:
1. There are a lot of class loaders, but I'd have to see some evidence
these are a problem. They could be combined if they are. There is
one loader for each expression in a quick definition, so they
shouldn't take up a lot of space.
2. 'update' does actual work at the end there. That generally shouldn't happen.
Mon, 2011-09-12, 22:17
#3
Re: Re: the art of doing nothing
On 9/12/11, Josh Suereth wrote:
> I'm 99% sure package doesn't do anything to prevent creating the jar/zip
> again if the files have not changed. Seems like an easy win here.
If we are referring to the default 'package' task, it does uptodate
checking based on the manifest, the input mappings, and timestamps.
If you change timestamps of input files, the paths that files are
mapped to, or change the contents of the manifest, the jar is
repackaged.
> On Mon, Sep 12, 2011 at 2:33 PM, Paul Phillips wrote:
>
>> Presently the time to do nothing in the scala build is around 30
>> seconds. By "nothing" I mean
>>
>> % sbt package
>> % sbt package # time elapsed of this one
Mon, 2011-09-12, 23:17
#4
Re: Re: the art of doing nothing
Yes, I think I'm somehow touching a file in every run. Isolating the issue now
On Sep 12, 2011 4:58 PM, "Mark Harrah" <dmharrah@gmail.com> wrote:> On 9/12/11, Josh Suereth <joshua.suereth@gmail.com> wrote:
>> I'm 99% sure package doesn't do anything to prevent creating the jar/zip
>> again if the files have not changed. Seems like an easy win here.
>
> If we are referring to the default 'package' task, it does uptodate
> checking based on the manifest, the input mappings, and timestamps.
> If you change timestamps of input files, the paths that files are
> mapped to, or change the contents of the manifest, the jar is
> repackaged.
>
>> On Mon, Sep 12, 2011 at 2:33 PM, Paul Phillips <paulp@improving.org> wrote:
>>
>>> Presently the time to do nothing in the scala build is around 30
>>> seconds. By "nothing" I mean
>>>
>>> % sbt package
>>> % sbt package # time elapsed of this one
Mon, 2011-09-12, 23:27
#5
Re: Re: the art of doing nothing
I think library.properties and compiler.properties are good candidates.
On 9/12/11, Josh Suereth wrote:
> Yes, I think I'm somehow touching a file in every run. Isolating the issue
> now
> On Sep 12, 2011 4:58 PM, "Mark Harrah" wrote:
>> On 9/12/11, Josh Suereth wrote:
>>> I'm 99% sure package doesn't do anything to prevent creating the jar/zip
>>> again if the files have not changed. Seems like an easy win here.
>>
>> If we are referring to the default 'package' task, it does uptodate
>> checking based on the manifest, the input mappings, and timestamps.
>> If you change timestamps of input files, the paths that files are
>> mapped to, or change the contents of the manifest, the jar is
>> repackaged.
>>
>>> On Mon, Sep 12, 2011 at 2:33 PM, Paul Phillips
> wrote:
>>>
>>>> Presently the time to do nothing in the scala build is around 30
>>>> seconds. By "nothing" I mean
>>>>
>>>> % sbt package
>>>> % sbt package # time elapsed of this one
>
Tue, 2011-09-13, 01:27
#6
Re: Re: the art of doing nothing
It's neither. Too many cooks in the kitchen in this case. Those two are sharing the same cache file by virtue of having the same target directory. Too many asusmptions I'm making while using SBT 0.10 here.
Basically, the Scala projects all share the same common root (file(".")), but I had missed assigning new target directories for the "packaging" projects. They were sharing the same cache directories and blowing each other awya. We're down to 3s to do nothing on my machine.
- Josh
On Mon, Sep 12, 2011 at 6:23 PM, Mark Harrah <dmharrah@gmail.com> wrote:
Basically, the Scala projects all share the same common root (file(".")), but I had missed assigning new target directories for the "packaging" projects. They were sharing the same cache directories and blowing each other awya. We're down to 3s to do nothing on my machine.
- Josh
On Mon, Sep 12, 2011 at 6:23 PM, Mark Harrah <dmharrah@gmail.com> wrote:
I think library.properties and compiler.properties are good candidates.
On 9/12/11, Josh Suereth <joshua.suereth@gmail.com> wrote:
> Yes, I think I'm somehow touching a file in every run. Isolating the issue
> now
> On Sep 12, 2011 4:58 PM, "Mark Harrah" <dmharrah@gmail.com> wrote:
>> On 9/12/11, Josh Suereth <joshua.suereth@gmail.com> wrote:
>>> I'm 99% sure package doesn't do anything to prevent creating the jar/zip
>>> again if the files have not changed. Seems like an easy win here.
>>
>> If we are referring to the default 'package' task, it does uptodate
>> checking based on the manifest, the input mappings, and timestamps.
>> If you change timestamps of input files, the paths that files are
>> mapped to, or change the contents of the manifest, the jar is
>> repackaged.
>>
>>> On Mon, Sep 12, 2011 at 2:33 PM, Paul Phillips <paulp@improving.org>
> wrote:
>>>
>>>> Presently the time to do nothing in the scala build is around 30
>>>> seconds. By "nothing" I mean
>>>>
>>>> % sbt package
>>>> % sbt package # time elapsed of this one
>
Tue, 2011-09-13, 01:37
#7
Re: Re: the art of doing nothing
Ah, I should mention just "sbt package" on the command line is still 19s. Lots of file I/O there.
On Mon, Sep 12, 2011 at 8:25 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
On Mon, Sep 12, 2011 at 8:25 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
It's neither. Too many cooks in the kitchen in this case. Those two are sharing the same cache file by virtue of having the same target directory. Too many asusmptions I'm making while using SBT 0.10 here.
Basically, the Scala projects all share the same common root (file(".")), but I had missed assigning new target directories for the "packaging" projects. They were sharing the same cache directories and blowing each other awya. We're down to 3s to do nothing on my machine.
- Josh
On Mon, Sep 12, 2011 at 6:23 PM, Mark Harrah <dmharrah@gmail.com> wrote:
I think library.properties and compiler.properties are good candidates.
On 9/12/11, Josh Suereth <joshua.suereth@gmail.com> wrote:
> Yes, I think I'm somehow touching a file in every run. Isolating the issue
> now
> On Sep 12, 2011 4:58 PM, "Mark Harrah" <dmharrah@gmail.com> wrote:
>> On 9/12/11, Josh Suereth <joshua.suereth@gmail.com> wrote:
>>> I'm 99% sure package doesn't do anything to prevent creating the jar/zip
>>> again if the files have not changed. Seems like an easy win here.
>>
>> If we are referring to the default 'package' task, it does uptodate
>> checking based on the manifest, the input mappings, and timestamps.
>> If you change timestamps of input files, the paths that files are
>> mapped to, or change the contents of the manifest, the jar is
>> repackaged.
>>
>>> On Mon, Sep 12, 2011 at 2:33 PM, Paul Phillips <paulp@improving.org>
> wrote:
>>>
>>>> Presently the time to do nothing in the scala build is around 30
>>>> seconds. By "nothing" I mean
>>>>
>>>> % sbt package
>>>> % sbt package # time elapsed of this one
>
On Mon, Sep 12, 2011 at 2:33 PM, Paul Phillips <paulp@improving.org> wrote: