We've had a customer complaining about the performance of generating pdfs using ActivePDF Toolkit over ASP.Net.
For the most part, we're taking existing, fielded pdf templates, filling them with instance data, and then shipping the bytes back down the IIS request stream.
I pulled the toolkit C# assembly into Reflector, and it appears to be a pretty thin veneer around the C++ code, so it looks like we have a lot of overhead marshaling bytes from the C# to the C++ and back before we fulfill the request. This is also in keeping with the memory footprint we see in IIS when we do this.
Where we can, I'm thinking of using fewer
TK.InputByteArray = PdfBytes; // marshaling the bytes from C# to C++
calls and replacing them with TK.OpenInputFile(path) calls to cut the C# -> C++ marshaling overhead...
But I got to wondering about how to cut the overhead of marshaling the result to the C# response stream.
Has anyone ever tried to use named pipes between C++ and C# to cut the byte shuffle down? If so, how did that work out?
and then having your C# code open "\\.\pipe\myrequestpipe" and read say 10k blocks from it and write them to Response.OutputStream.
Our customers producing pdfs in Asia are getting 20+ meg pdf results, so the overhead of having 20 meg in the C++, 20 meg in C# after the TK.BinaryImage(), and 20 meg in Response.OutputStream adds up.
If I can drop the 20 meg in the middle out with a named pipe that could help the load.
Please sign in to leave a comment.