The Lab has released a curious new project viewer on Wednesday March 26th.
Project Zipper (currently version 3.7.2.286810 is designed to speed-up the viewer installation process. A blog post on the viewer has also been released, which reads in full:
As we continue to work on improving the Second Life experience, one challenge we’ve been tackling is the length of the Viewer installation process. No one likes waiting, and now with Project Zipper, you don’t have to!
With the project Viewer available today, there’s really only one thing different – the installation is super fast. Rather than waiting for install to complete, you’ll quickly be in Second Life doing what you love.
Try out Project Zipper with the project Viewer here.
This is still a project Viewer, and if you find bugs while testing it out, please let us know by filing them in BUG project in JIRA.
To try-out the new installation process, I opted to run a clean install of the current release version of the viewer (3.7.2.286707) and a similar clean install with the Project Zipper viewer, and carry out a rough-and-ready timing between the two. I starting the stopwatch on clicking the Install button, and stopped when the Start Second Life Now prompt appeared. The results were:
- Second Life release viewer 3.7.2.286707: 35.6 seconds
- Second Life Project Zipper viewer 3.7.2.286810: 16.4 seconds.
Nothing has physically changed in what you see during the installation process, but the faster time is pretty clear (at least on my system – YMMV depending on CPU, disk speed, etc).
This seems to be an odd change to make, and I can’t help but wonder if it is indicative of something else coming down the pipe. Time will tell on that.
Those wishing to try out the project viewer, which I believe should be fully up to par with the HTTP updates in the release viewer, can do so by following the links above in the quoted LL blog post, or below.
Inara Pey: Living in a Modemworld 
Someone at Linden Lab (a developer? a marketer? more than one person?) actually thought that 35 *seconds* for installation is too long and might dissuade people from using Second Life? I mean, how long does it typically take to download the silly thing? Or from pressing enter after putting in your password until you actually appear in-world? Or until you actually *rez* in-world? Or until in-world rezzes for you? I know that different people work on different things, and making one improvement often has no affect whatsoever on the capacity to work on other improvements. But I agree that this particular change seems rather silly on its own.
LikeLike
I find it odd that they would prioritize this. Install time is not something I see as a big annoyance for SL users.
LikeLike
I have never understood claims that Second Life has a large client. I’m not saying there’s anything wrong with this concept of a speedier install but plenty of people download whopping upgrades for things like World Of Warcraft, the SL client is pretty tiny.
LikeLike
I agree, I have a,ways thought it was a short install even compared to simple browser plugins like Flash player. Hope they don’t start to add untick here NOT to install virus checkers, Google toolbars and all sorts of third party things… they are a pain.
LikeLike
Now there’s an idea, let’s use the 2/3s we saved for installing shareware and bloatware!
LikeLike
Mmmm BonziBuddy
LikeLike
At the Firestorm meeting Jessica told us that the FS 64 bit install will be very slow (15 minutes or so!). Maybe there is some kind of competition. 🙂
LikeLike
I’ve just tried the new Firestorm 64-bit installer (at least, I assume it’s the new one; might just be something for the latest beta pre-release, and it is faster that the previous installer, but the time is still measured in minutes rather than seconds. So if it is a race, the Lab’s hare can still afford that nap without worries 😀 .
LikeLike
The short install time is a side effect.
The viewer now uses one big file for resources rather than hundreds of separate files. This is much faster to write to disk.
I would be more interested in how it performs running and how much overhead is added. If there is a performance decrease then you have to wonder why even use this approach.
The viewer UI is based on a large number of XML files, these are read and processed over and over by an external library. Say you have 500 friends, every item in your friends list is one file being read and parsed 500 times (it’s way worse .. but you get the idea). This adds an extra layer between the external libraries and the XML and may even add compression into the equation (that would happen on the same thread as the viewer).
LikeLike
Thanks Trinity, that would be something that does make sense to me!
LikeLike
This may be because of the auto-update “feature”. If it is fast enough most people won’t even notice it happening. There will probably be fewer opt-outs.
LikeLike