Hi Chris,
The database of the application grows and the perfomance is decreased, so that's why i need to recover free space (because on certain moment of business activity, a lot of data is deleted, and a lot of free space that database has to handle). I can determine a database size for establishing a significant perfomance loss, and if i can do a rebuild when the data is deleted then the size of database could be 10 times less sized.
With that, the application perfomance is greatly increased.
The data is bi-directional, and the data i'm syncyig is available in this post: Problems with Publications when migrating Ultralite DB v.11 to v.16
I think that the "working set size" is also affected by publications DDL, as explained last EBF 23041 Build #1501 - Engineering Case #736683:
An UltraLite database could have unnecessarily grown by a small amount during
each synchronization, or as a result of executing publication DDL. This has
now been corrected.
Among other things that might increase database size (i guess). I'm Testing right now the new version and seems that with the same set of data the database size is decreased. I have not final results yet, but as soon as i get the results i will post it.
Anyway, i still think that should be a good idea to have a "shrink" method to be used on mobile applications to increase perfomance and reduce space, specially critical on old devices (windows mobile based).
Update: Size of database at it's Maximum critical Size or Working Set Size (v11) : 10Mb. Size after unload - load : 617Kb.