TOT: Crap coding or crap coding?

[fred]

While completing an online submittable pdf Corporation Tax return and accounts I noticed that the blank 1.8MB pdf doc set takes up 250MB of memory when opened in Acrobat 10, expanding to 325MB by the time it is ready for submission.

My working copy doc is 110k and my self calculating xls with all the data is 33k.

Sooooo, is this coding bloat from HMRC, Adobe or both?

[John Rumm]

Partly a reflection on the fact the the PDF render engine will in effect need to provide a complete postscript virtual machine to render the doc. Also you will need space to load and rasterise all the fonts used for screen work. The document files will also often include a fair amount of compression while on disk these days.

Having said that, Adobe reader has been growing in size for years and is significantly larger and slower than many of the competing readers.

[fred]

Huh :-?

I decided to have a bit of a play:

I tried going back in history a bit to see what older, non interactive CT600 (Corporation tax) forms used when opened in Acrobat 8 pro and Acrobat 10 (X) reader.

Acro 8 used between 33 and 38MB between blank and filled in using the typewriter tool (87-122k pdf).

Acro 10 used a measly 17M when blank but 44MB when completed.

As these older docs have the same fonts as modern ones and the same rendering requirements for a single page it seems reasonable to say that this is the base load for fonts and rendering.

When I moved over to the interactive pdfs used for companies house submissions it started moving up to bigger numbers:

Acro 8 used 63M for an uncompleted 382k pdf to 80M for a 640k completed one.

Acro 10 used 89M and 96M for the same docs.

These are v simple docs content wise so I can't see that the rendering or font handling is more complex . The interactive content seems to be where the hit is coming from. Bump the complexity of the doc up to a full CT and accounts submission pack and you get the 250 - 325MB that I was seeing.

Chop off that 40 odd MB for the fonts and single page rendering and we're getting 40-280MB for the interactive content. Call me old fashioned but that seems excessive to me. Are they coding it all in incredibly inefficient interpretive macros?

Yep, 20-40% more memory used on the new version of Acro on the interactive doc.

Unfortunately I'm stuck with it as AFAIAA it is the only one that will work with HMRC.

Oh, and 70s to load the doc, no hint that anything is in progress until the last few seconds when the Acro window opens and the page comes up.

2-4s for check buttons to change state.

Lets hope Adobe never write any code for set top boxes or they'll quadruple in price and power consumption performing the same tasks as today.

[John Rumm]

My point being that there is more to opening and rendering a PDF than say a text file or word processor doc - so don't be surprised if a 100K PDF turns into something orders of magnitude larger in memory.

I agree however that it does seem to use more ram than one might expect

- and is getting bigger. (Not helped by the fact they keep adding new supported data types and hence the need to decode video etc in the body of a doc - I would not be surprised find they have stuffed a flash player in there as well now).

[snip]

Well it is probably Javascript if that is what you mean... ;-)

I have created a few automated docs in Agrobat 5, and you don't really need much code for doing basic sums with form fields... much of its going to be simple stuff like this bit which iterates through fields on an invoice and totals them and works out the vat:

var subtotal = this.getField("SubTotal"); subtotal.value = 0 ;

for( var i = 1 ; i > Having said that, Adobe reader has been growing in size for years and is

I just tried on Acrobat 5 (note the full product, not just the reader).

35,796K mem usage in task manger on XP with just Acrobat loaded. Surprisingly only rising to 36,900K with a doc loaded (which was 224K on disk).

Same doc in Foxit Reader take the footprint from 10,392K loaded empty, to 20,112K with the 224K doc.

Normally a problem with docs that include rights management which is not catered for in some readers. Form fields and scripted content seem to work in most.

I think they already do... flash seems to work its way into many things these days. (although that was not an Adobe product initially)

[Brian Gaff]

Mostly adobe but there are probably graphics as well. Brian

[fred]

Oh, I'd forgotten about that (how could I).

Thanks for sharing on your work and docs although it still seems a mystery why it needs that much mem. I wish I'd filled in the feedback form now, maybe I can go back to that.

Btw, the original Huh :-? wasn't for lack of clarity on your part but lack of knowledge on my part making a second read necessary.

[John Rumm]

Well to be fair I was probably probably being a little too "concise" to avoid the risks of teaching granny to suck eggs etc.