Wt

It turns out that further patches are needed against src/fcgi/Server.C and src/web/RefEncoder.C . I've got some experimental patches about to be tested, and can add those later.

I suppose the saving is significant. The application is built using static boost, static fcgi and static wt (but dynamic C/C libraries) and the difference in size with/without boost::regex is around 100KiB. Still, compared to the ugliness/potential bugginess of two code paths, it may not be worth maintaining this option.

Without boost::regex:

lwithers@rhodium Pt-web-build $ size Pt-web/obj/Pt-web.wt
   text    data     bss     dec     hex filename
3099086    6800   17376 3123262  2fa83e Pt-web/obj/Pt-web.wt

With boost::regex:

lwithers@rhodium Pt-web-build $ !size
size Pt-web/obj/Pt-web.wt
   text    data     bss     dec     hex filename
3201493    8264   17328 3227085  313dcd Pt-web/obj/Pt-web.wt

Hi,

Yes, I did follow the steps on that page (yes, a little outdated, but nothing that some digging/experimentation can't solve). On the x86_64 platform there has been a bit of an increase in filesize over time (note: all sizes after stripping debug symbols):

lwithers@amethyst 2014-11-01-wt-filesize $ ls -lh */src/lib*.so.?.?.?
-rwxr-xr-x 1 lwithers lwithers 6.9M Nov 17 14:28 3.3.0/src/libwt.so.3.3.0
-rwxr-xr-x 1 lwithers lwithers 8.0M Nov 17 14:28 3.3.1/src/libwt.so.3.3.1
-rwxr-xr-x 1 lwithers lwithers 8.5M Nov 17 14:28 3.3.2/src/libwt.so.3.3.2
-rwxr-xr-x 1 lwithers lwithers 8.5M Nov 17 14:28 3.3.3/src/libwt.so.3.3.3
-rwxr-xr-x 1 lwithers lwithers 8.8M Nov 17 14:28 3.3.4-rc1/src/libwt.so.3.3.4

But this was massively amplified on the ARM (we have a PXA270 and an ARM926EJS platform), where 3.3.0 was 6.8M and 3.3.4-rc1 was 20M. I wasn't able to determine why the code size increased so significantly. Using the hidden visibility options reduced the compiled library to around 12M. And certainly the largest object file (8M unstripped) in the 3.3.4-rc1 build is the Spirit-based CSS parser. But all of the object files just seemed to massively increase in size.

The most elegant solution was switching to a static build and using function/data sections. This let me get the executable down much smaller, so that's what I ended up doing. As a bonus it also starts a fair bit faster too now, and I can afford to ship a version with debug symbols on the x86 platform.

The regex stuff was a step along the route. As I say, 100K is not much in the big scheme of things, it's really your call about whether it's worth maintaining the option or not. The potential for bugs is high!