Very little = nothing.
The terms PPL and Packed never appear in the release notes.
There was some curious thing about a 'Fast File Format'. I'll have to learn more about that. Sounds interesting.
Hm... looks like it didn't make it to the final draft of the upgrade notes. I guess since it was all behind-the-scenes stuff, someone thought we didn't need to talk about it? That's disappointing... it's a pretty nice chunk of work.
So, you read that feature tidbit in the upgrade notes about the fast file format for DLLs... it's an option for DLLs, but it is always on for PPLs, which is why you don't see an option for it. The internal file format was completely rejiggered, the build process was streamlined, and a huge effort went into stabilization. As a result, PPLs build faster, have a MUCH smaller on-disk footprint, and load blazing fast -- I believe in pretty much all cases, a hierarchy of VIs in a PPL will load faster than a hierarchy of VIs in any other storage format, including LLBs, which until 2015 held the record.
Why isn't it always on for DLLs? There's some questionable things that people can apparently do with LV-built DLLs that (probably) should never have worked in the first place and enabling this format breaks those techniques. I think 99% of DLL builders will be just fine, but there's a strong allergy to anything that breaks user workflows on upgrades... that 1% generally turns out to be some high dollar, high profile user. :-)
Back to the subject of PPLs, is there an easy (or at least straight-forward) way to convert an .lvlib to a .lvlibp and then have all the code in a project that was calling code in the original .lvlib automaticlaly point to the .lvlibp versions?
If I could do this easily, I could start converting my libraries to PPLs without major headaches.
Also, this would allow me to develop a complex application in the IDE with the ability to edit the code that will eventually live in a PPL, but then convert over to the PPL when that code is stable.
Bonus would be the ability to effortlessly go back to the .lvlib if the PPL turns out to not be stable or need some major refactoring.
The thing about PPPLs that bothers me is how it seems like a one way street and hard to debug.
1) First and foremost, use a repository to back up/check in your project before you start. That will also allow you to recover if your investment into PPLs come up with too many issues for you to want to work through.
2) I'd highly recommened that you create a seperate project for your Libraries. They should be anything more thena project file with the lvlib included. This will allow you to work on the different libraries (hopefully indepentently) from your execution. In the Build Specification, setup your library to be converted into a packed library. This can take a little bit of time if you have dozens of libraries and interaction between them.
3)Finally, in your main application, you can right click the lvlib file and second from bottom select "Replace with a packed library..." This will ask you to browse for the library. Once you select it, it'll attempt to update every link in the code to point to the PPL vs the library VIs. This will take time for the script to run.
4)Once complete, attempt your code to see if everything is not broken, then if it's working. It should, but there's things that may be specific to your imiplementation that could cause it to not work properly.
5)If everything works, commit your changes into your repository. If not, you can easily revert your changes.
"I won't be wronged. I won't be insulted. I won't be laid a-hand on. I don't do these things to other people, and I require the same from them." John Bernard Books