Compact Framework Trial and Error

23Dec02

I’ve “finished” cache, serialization, and storage for the .NET version of Pocket Blog. The entry management module should be done, but when I started updating my test application to thoroughly stress everything I ran into problems with my HTTP module. I turned to Google: HttpWebResponse “Compact Framework”. Naturally, the first link is me bitching about Beta 1 of the SDE back in August, and the final problem I mentioned with GetResponseStream is exactly what I’m experiencing now. Probably because it’s the same code. Doh!

All the sample code I found for GetResponseStream either passed the stream directly to something else (ie: BinaryWriter) or read the bytes one at a time in a loop and and caught the ArgumentException to break out. I’m planning to re-factor the HTTP module, but I didn’t want to do that tonight.

With some trial and error I figured out that the Read method for that stream doesn’t want to return more than ~1850 bytes on the first call. Asking for the rest on a subsequent call works fine. There’s no logical reason for this, I’m making synchronous calls, all the bytes should already be there…

With that fixed, my new problem is that serialization is seriously slow. By the stopwatch method it is taking ~16 seconds to convert and store an array of 20 hashtables. I’m recycling my XML-RPC serialization routines for this, because the Compact Framework doesn’t provide serialization. Why re-invent the wheel a third time?

I’m recalling that I had the same performance problem with the eVB version of Pocket Blog, which I believe I traced to XMLDOM’s AppendChild method being extremely slow on the Pocket PC. My solution there was to simulate structs using fixed arrays which could be stored directly. VB.NET offers compatible storage routines, but the CF doesn’t support them — I’d bet that they’ve been updated to use .NET serialization.

And the CF doesn’t support profiling either. Ugh.

Update #1: Wrapped some timers around AppendChild, the rest of the serialization / storage code executes in under a second. Yow.

Update #2: Uhhh, using a release build runs much faster, ~3 seconds. I can live with that for now, it’s minor compared to the 15 seconds it takes to transfer a 23KB blogger.getRecentPosts response in the first place. If I ever get really bored, I’ll give raw sockets a try…


 


Flickr Photos