There are many advantages to archives.
Open Packages have several performance characteristics worth understanding.
An Open Package is an archive that can be loaded into memory.
When we use OP to Open Packages, we are reading the files into memory.
Please note the plural.
We have an entire filesystem in memory!
This means that every operation on that filesystem is also in memory.
And this means that the disk is involved much less often.
This is especially helpful for home applications and physical servers.
Disks take more time to access than memory.
When dealing with lots of files, this tends to be especially painful.
Each read of the disk could be anywhere, and seek times vary.
By using packages, we eliminate our disk impact. Instead, we impact memory.
Our reduced disk impact makes our reduced memory impact even more priceless.
Normally, if we were mapping files to memory, we'd expect to see a memory impact roughly equal to the file size.
You might get clever, and use some light compression. At this point you are simply making your own package, anyway.
Because we are storing an archive in memory, we are getting compression for free.
The data is all implicitly compressed and decompressed as we read and write content.
This is quite nice!
It also offers some interesting benefits.
Once a package is loaded into memory, every change to that package is to the exact same object.
This means that packages are easy to pass around in memory.
Multiple thread jobs can also access the same package.
Therefore, changes to a loaded package are nearly instant.
The change does not need to propagate, because it is the same object.
This is also true for package parts. Once the object exists, we are not recreating it, we are simply sharing a reference to it.
And that reference is consistent.
This enables the core functionality of Open Package:
We can easily extend objects in PowerShell.
This happens in three ways:
- We can use
Add-Memberto add information to an instance - We can use
Update-TypeDatato add information about a type - We can load a
.types.ps1xml, which contains type data.
OP is built by extending the types .NET uses to load packages.
Primarily:
System.IO.Packaging.PackageSystem.IO.Packaging.PackagePart
Each instance may also Add-Member to it's heart's content.
If you want to make your own methods for working with a package, just Add-Member
Speaking of adding things, let's talk layers
We can use packages in layers.
This is a lot like how containers work: Each layer in a container is effectively a filesystem.
The difference is that, in memory, we can add layers as we need, in any order.
We can allow some packages to be writeable, and others to not be.
We can serve one layer that provides an experience around any files it can fetch.
This can allow us to build applications as layers, instead of making everything a monolith.
We can also swap out layers.
For an example, image a photo viewer.
All it needs to do is render images, but there's lot of ways to do this.
We can easily make a photo viewer as it's own package, load it with our package containing photos, and have ourselves a gallery!