2011 MBA vs 2012 MBA ssd performance?

[Lax1085]

is there a noticeable difference between without looking at the specs?

 

[NeonBible]

Edit: Deleted post. Misread the title.

 

[asting]

If you're copying files definitely. That coupled with USB 3.0 gives a nice hearty boost in performance.

Outside of that situation it becomes much more subjective.

 

[Blackened Apple]

Boot times are reportedly about 5 seconds quicker. And big apps should load a bit faster too (smaller ones load pretty much instantly anyway...).

 

[dmelgar]

is there a noticeable difference between without looking at the specs?

2012 is much faster than 2011 drives. 2011 was basically using same drives as 2010. As much as 200mb/sec. 2012 drives read as fast as 450mb/sec. Definitely noticeable depending on what you're doing. Write speeds are somewhat different. 2012 Samsung much faster at 400+ while Toshiba is only 240. Makes a noticeable difference for some length operations such as installing ML. Much faster on Samsung drive.

 

[theSeb]

Unless you're doing many things at the same time, which are all disk bound, then it's not a difference that a normal person would notice. I have a 2011 MBA, a Mac Mini with a vertex 3 and a rMBP with the Samsung 830 based flash storage. Unless you're copying 30 GBs files all day, an average person would not be able to tell the difference between these 3 SSDs in a blind test, even though the vertex is quite lot faster in benchmarks than the 2011 MBA's SSD and the Samsung 830 is even faster.

 

[dmelgar]

Unless you're doing many things at the same time, which are all disk bound, then it's not a difference that a normal person would notice. I have a 2011 MBA, a Mac Mini with a vertex 3 and a rMBP with the Samsung 830 based flash storage. Unless you're copying 30 GBs files all day, an average person would not be able to tell the difference between these 3 SSDs in a blind test, even though the vertex is quite lot faster in benchmarks than the 2011 MBA's SSD and the Samsung 830 is even faster.

Never know what a "average" person is.

I do software development and runs builds all the time. This is very disk intensive, not so much with big files, but lots of little files. SSD speed makes a much bigger difference to me than CPU speed.
I also have multiple userids on my MBA including one with the old FileVault. SSD speed also makes a huge difference opening that up.
If you're just surfing the web, you don't need anywhere near this powerful a machine anyway.

 

[asting]

2012 is much faster than 2011 drives. 2011 was basically using same drives as 2010. As much as 200mb/sec. 2012 drives read as fast as 450mb/sec. Definitely noticeable depending on what you're doing. Write speeds are somewhat different. 2012 Samsung much faster at 400+ while Toshiba is only 240. Makes a noticeable difference for some length operations such as installing ML. Much faster on Samsung drive.

You're wrong about the Toshiba drive. They get worse performance in non compressible data but on par or better for compressible than the Samsung.

 

[theSeb]

Never know what a "average" person is.

I do software development and runs builds all the time. This is very disk intensive, not so much with big files, but lots of little files. SSD speed makes a much bigger difference to me than CPU speed.
I also have multiple userids on my MBA including one with the old FileVault. SSD speed also makes a huge difference opening that up.
If you're just surfing the web, you don't need anywhere near this powerful a machine anyway.

Running build after build is not disk intensive at all - only your first build will be. The source files are tiny, in the big scheme of things, and Xcode is very efficient in caching them into ram. mac performance guide has some excellent benches on this topic, which clearly show that your builds are CPU dependent, as long as you have a decent amount of RAM. The guy even created a RAM drive, which is more than 10x faster than a fast SSD, and ran the builds from there. The speed increase from mechanical HDD to SSD to ram drive were tiny.

Edit: actually we've had this conversation before and I've already supplied the links.

 

[dmelgar]

Running build after build is not disk intensive at all - only your first build will be. The source files are tiny, in the big scheme of things, and Xcode is very efficient in caching them into ram. mac performance guide has some excellent benches on this topic, which clearly show that your builds are CPU dependent, as long as you have a decent amount of RAM. The guy even created a RAM drive, which is more than 10x faster than a fast SSD, and ran the builds from there. The speed increase from mechanical HDD to SSD to ram drive were tiny.

Edit: actually we've had this conversation before and I've already supplied the links.

Xcode doesn't cache. Mac OSX does. That's the blue area you see in activity monitor of memory usage.
RAM disk is nonsensical on a Unix system for the same reason. Mac OS X does a better job caching than a RAM disk would provide.
If you have enough ram to cache everything you need, then yes, SSD speed won't be as important after you've done it once. In my case because I have other things going on, running simulator, my app, browser, etc. in 4GB RAM, the cache helps but SSD speed difference is noticeable.

 

[theSeb]

Xcode doesn't cache. Mac OSX does. That's the blue area you see in activity monitor of memory usage.
RAM disk is nonsensical on a Unix system for the same reason. Mac OS X does a better job caching than a RAM disk would provide.
If you have enough ram to cache everything you need, then yes, SSD speed won't be as important after you've done it once. In my case because I have other things going on, running simulator, my app, browser, etc. in 4GB RAM, the cache helps but SSD speed difference is noticeable.

Of course Xcode caches. Practically all compilers do this as part of the build process so not all files are need to be read and recompiled each time you do a build (precompiled headers etc). All of this is in the DerivedData folder in your Library, unless you've changed the default location. There is no need to get pedantic about what Xcode does versus what OS X is doing in the background or to tell me about blue colours.

 

[dmelgar]

Of course Xcode caches. Practically all compilers do this as part of the build process so not all files are need to be read and recompiled each time you do a build (precompiled headers etc). All of this is in the DerivedData folder in your Library, unless you've changed the default location. There is no need to get pedantic about what Xcode does versus what OS X is doing in the background or to tell me about blue colours.

You're saying it creates files to cache the data... As in creating FILES. And this proves the point about RAM cache vs. SSD speed how?

A cache is used to speed up access to a slower medium. Items needed frequently are read from the cache instead of from the slower medium. Mac OS X will use practically all available free memory as a cache for items read from disk. RAM is faster than disk.

Xcode precompiling files is orthogonal to the RAM cache. It continues to illustrate the point that there are many little files that Xcode accesses while doing a build & run step. If everything fits in RAM, then it does get much faster after the 1st run. If everything doesn't fit in RAM, or RAM is needed for another application, it will have to reload.

SSD is much faster than traditional hard drives. SSD in the 2012 MBA reads at 450MB/sec, way above 30MB that a hard drive often benchmarks at. That makes a big difference when reading especially lots of small files which end up as acting like random access that is much slower for both SSD and especially hard drives.

If you don't want or need a fast drive, get a Macbook Pro. You can get faster CPU for less money with a glacially slow hard drive since it all gets cached in RAM anyway...
Have fun with that.

To repeat some old personal benchmarks I did,
Comparing a 2009 MBP 2.26GHz to a 2010 1.6ghz MBA, both with 4GB of RAM:
- Clean compile of my biggest project was slightly faster on the MBP.
- Clean compile and run in simulator (launching simulator) was faster on the MBA. The MBA would catch up and win because it launches the simulator faster.
- Switching userids to another id using original filevault. MBA was 10x faster than the MBP.
- For most every real world end to end scenario I could come up with, even the 2010 MBA was faster than the MBP.
- The only scenario I occasionally do that was faster on the MBP was handbrake video compression. That was 2x faster on the MBP.

Clearly the CPU in the 2010 MBA was much slower yet it performed better and generally felt much more responsive, not slightly, but dramatically in many cases. In my day to day activities, the SSD speed made the difference.

If you loaded up a MBP with 8 or 16GB of RAM, maxed out the CPU, and used a slow hard drive, you might get decent performance after everything is run once and gets cached.

The SSD speed is also nice if you do end up swapping. 450MB/sec is so fast that swapping doesn't slow it down as bad as a hard drive where it often feels that the machine just stops when it starts swapping.

Of course YMMV. If in doubt test it. I put some of my typical applications on a flash drive. Take it to a store & try it out.

 

[theSeb]

You're saying it creates files to cache the data... As in creating FILES. And this proves the point about RAM cache vs. SSD speed how?

Creating these precompiled files is not a massive operation in terms of disk usage. Don't forget we're dealing with source code files, which are usually a couple of kilo bytes big.

Throwing numbers around without any context does not really prove any point. Sure, the Samsung 830 based flash storage can do around 450 MB/s reads, but it achieves those speeds when reading a large sequential file (gigabytes worth). A 3.5" 7200 RPM will do around 150-170 MB/s in those situations. A 2.5" 7200 RPM would do around 90-110 MB/s.

The flash storage won't hit anywhere close to those numbers reading small source code files and your other resources for compilation. RAM is more than 10 times faster than 450 MB/s and yet benchmarks clearly show that there is no advantage to build times when building off a SSD or a RAM drive.

Therefore to suggest that compilation times will be faster on the 2012 MBA in comparison to the 2011 MBA because of the SSD speed difference is a fallacy. The benchmarks also show that even a mechanical HDD does not slow down the compile times, so why would there be a difference between the 2011 MBA SSD and the 2012's SSD? Xcode compile times are bound by the CPU and RAM to a smaller extent. Again though, it does not matter that you're running your browser and other things at the same time. Consider how big your source code actually is. I've worked on quite a lot of large scale enterprise applications and even then the source code is in megabytes, not gigabytes. It will easily fit into the RAM and your storage speed is not a factor in compile times. Even if you're paging out the differences between the 2011 and the 2012 SSDs will not be noticeable.

This does not apply to Xcode only. You'll find the same thing with Visual Studio. Compile times are bound by the CPU and you can prove this to yourself by googling. Example:

http://stackoverflow.com/questions/...e-big-improvements-real-usage-stories-no-theo

Will everything feel more responsive with a SSD as opposed to a HDD? Yes, of course it will. But, again, that sort of thing won't be noticeable when going from a 2011 MBA to a 2012 MBA just because the SSD is faster. Your application might open 0.5 seconds faster. That's why SSD benchmarks are massively intensive operations with lots of things happening at the same time to try and show differences between SSDs. Otherwise you'll find that they all perform nearly the same in things like UI response (opening and closing apps)

I am going to repeat what I've said previously. Unless you're copying or working with large files (e.g. batch job to process lots of raw photo files or similar), then you won't notice a huge difference between the 2011 MBA SSD and the 2012 MBA SSD.

I haven't bothered redoing a lot of my benchmarks using the "fast" Samsung 830 in my rMBP, but I can show you the differences in the real world between the "fast" Vertex 3 and the "slow" SSD in the 2011 MBA.

Combining two 11 MB files in Excel using an automator action... real world difference? 1 second. Would the user notice that? No. Don't forget we're also talking about a ULV 1.8 GHz dual core vs a 2 GHz quad core. The benchmark actually includes opening Excel and the two 11 MB files as well before combining them.

The graph below really illustrates my point about real world use. This was a very intensive operation in terms of RAM and disk activity. There are more than 16 GBs of page outs at the end. The 4 GB Mini Server with a mechanical 7200 RPM really suffered here due to the large number of page outs. We basically got into a disk thrashing scenario. Upping the RAM to 8 GBs and leaving the mechanical HDD made a huge difference and the time came down to 287 seconds.

But what about the 2011 MBA with 4 GBs of RAM vs the Mini Server 4GB of RAM and a "fast" Vertex 3? The "fast" Vertex 3 managed to complete the operation in 300 seconds. The "slow" Samsung in the 2011 MBA managed to complete this in 303 seconds. Would the user notice the difference? No.

There were a lot of page outs and a lot of disk activity. Yet the "slow" SSD manages to keep up with the "fast" SSD. Synthetic benchmarks are great to show the differences between SSDs, but in a real world scenario those differences are usually barely noticeable to the user. The difference in compile times between the 2011 and the 2012 MBA due to the SSD speed would not be noticeable. The CPU would make a difference, if one went for a faster CPU configurations.

Copying a large file? Sure, that would be noticeable but that has little to do with SSD performance when it comes to compile times, paging out or the topic we're debating.

 

[austinguy23]

The SSD of the 2012 MBA is considerably faster than the previous year's. There are vids on YouTube showing the comparison. Also, there are quite a few articles online discussing the big performance bump going to SATA 3.0.

 

[dmelgar]

Creating these precompiled files is not a massive operation in terms of disk usage. Don't forget we're dealing with source code files, which are usually a couple of kilo bytes big.

Throwing numbers around without any context does not really prove any point. Sure, the Samsung 830 based flash storage can do around 450 MB/s reads, but it achieves those speeds when reading a large sequential file (gigabytes worth). A 3.5" 7200 RPM will do around 150-170 MB/s in those situations. A 2.5" 7200 RPM would do around 90-110 MB/s.

The flash storage won't hit anywhere close to those numbers reading small source code files and your other resources for compilation. RAM is more than 10 times faster than 450 MB/s and yet benchmarks clearly show that there is no advantage to build times when building off a SSD or a RAM drive.

Therefore to suggest that compilation times will be faster on the 2012 MBA in comparison to the 2011 MBA because of the SSD speed difference is a fallacy. The benchmarks also show that even a mechanical HDD does not slow down the compile times, so why would there be a difference between the 2011 MBA SSD and the 2012's SSD? Xcode compile times are bound by the CPU and RAM to a smaller extent. Again though, it does not matter that you're running your browser and other things at the same time. Consider how big your source code actually is. I've worked on quite a lot of large scale enterprise applications and even then the source code is in megabytes, not gigabytes. It will easily fit into the RAM and your storage speed is not a factor in compile times. Even if you're paging out the differences between the 2011 and the 2012 SSDs will not be noticeable.

This does not apply to Xcode only. You'll find the same thing with Visual Studio. Compile times are bound by the CPU and you can prove this to yourself by googling. Example:

http://stackoverflow.com/questions/...e-big-improvements-real-usage-stories-no-theo

Will everything feel more responsive with a SSD as opposed to a HDD? Yes, of course it will. But, again, that sort of thing won't be noticeable when going from a 2011 MBA to a 2012 MBA just because the SSD is faster. Your application might open 0.5 seconds faster. That's why SSD benchmarks are massively intensive operations with lots of things happening at the same time to try and show differences between SSDs. Otherwise you'll find that they all perform nearly the same in things like UI response (opening and closing apps)

I am going to repeat what I've said previously. Unless you're copying or working with large files (e.g. batch job to process lots of raw photo files or similar), then you won't notice a huge difference between the 2011 MBA SSD and the 2012 MBA SSD.

I haven't bothered redoing a lot of my benchmarks using the "fast" Samsung 830 in my rMBP, but I can show you the differences in the real world between the "fast" Vertex 3 and the "slow" SSD in the 2011 MBA.

Combining two 11 MB files in Excel using an automator action... real world difference? 1 second. Would the user notice that? No. Don't forget we're also talking about a ULV 1.8 GHz dual core vs a 2 GHz quad core. The benchmark actually includes opening Excel and the two 11 MB files as well before combining them.

The graph below really illustrates my point about real world use. This was a very intensive operation in terms of RAM and disk activity. There are more than 16 GBs of page outs at the end. The 4 GB Mini Server with a mechanical 7200 RPM really suffered here due to the large number of page outs. We basically got into a disk thrashing scenario. Upping the RAM to 8 GBs and leaving the mechanical HDD made a huge difference and the time came down to 287 seconds.

But what about the 2011 MBA with 4 GBs of RAM vs the Mini Server 4GB of RAM and a "fast" Vertex 3? The "fast" Vertex 3 managed to complete the operation in 300 seconds. The "slow" Samsung in the 2011 MBA managed to complete this in 303 seconds. Would the user notice the difference? No.

There were a lot of page outs and a lot of disk activity. Yet the "slow" SSD manages to keep up with the "fast" SSD. Synthetic benchmarks are great to show the differences between SSDs, but in a real world scenario those differences are usually barely noticeable to the user. The difference in compile times between the 2011 and the 2012 MBA due to the SSD speed would not be noticeable. The CPU would make a difference, if one went for a faster CPU configurations.

Copying a large file? Sure, that would be noticeable but that has little to do with SSD performance when it comes to compile times, paging out or the topic we're debating.

Image

I hear you and understand what you're saying. There are many activities for which CPU speed is a bigger factor vs. the already fast speed of even slower SSDs.
But I still say that a faster SSD is noticeable.
Its not just the narrow window of when a project is technically compiling, its startup time of the environment, ie Xcode, the compiler (llvm), the simulator, debugger etc. I have tried to make the point that I'm discussing broader activities, i.e. clean build and run vs. strictly timing just a compile.
Not sure your point about large vs. small files.
SSDs speed advantage over HDD for small files is even greater. I have always said its lots of small files being read, that is precisely why its faster with an SSD.
1 second faster times can be noticeable if its a significant percentage of the time.
Often, when launching an application for the first time the elapsed time is a direct relation to load speed. Installing ML is an example of a largely disk bound activity that is noticeably faster with the faster SSD.
In any case, it doesn't seem that I will affect your opinion so I will let it lie.

 

[stu.h]

Boot times are reportedly about 5 seconds quicker. And big apps should load a bit faster too (smaller ones load pretty much instantly anyway...).

So it boots up in 2 seconds?