Re: serialiazation, carchive issue with vc8 and vc6

I don't know about "proof of concept", but like most
wrappers (I consider
anything that ends up in the SDK, a wrapper), you have to
know what its
capabilities are before you use it. Obviously, this only
refers to apps where
performance is an issue (reliablilty is a given - I can't
imagine writting
any app other than a prototype where I wouldn't be
concerned about
robustness).

As it turns out, we had to bypass serialize in some of the
collection
classes. When we were profiling, we found an inordinate
amount of time being
spent in some of them. It's pretty simple if speed is
important. Serialize
the version (every object that's serialized has a version
up front), the
count, and loop while adding the necessary members.

We didn't start this way, but every major release has at
least doubled the
capacity. The last release went from supporting around
20,000 items to
250,000. It was an interesting exercise. What was
tolerable at 20K was dismal
at 250K. Only then did we resort to tatics such as
bit-fields for boolean
members and the bypassing of some of the serialization
methods. At the leaf
elements, we would serialize a version then the collection
as we couldn't
afford the overhead of a version in the object.

Bottom line is as long as you're careful and pay attention
(of course you
have to know what you're doing), you can push Windows and
MFC/Visual Studio
way beyond what most people would imagine. The 250K item
server was running
on a Dell Workstation 530 (dual 1.7GHz Xeon) and archiving
250K+ items a
minute, and processing 18,000 TCP packets/sec (2 gigabit
NICs in a team).
Believe it or not, the limit we hit was the TCP stack (we
actually test the
limits so we know where they are). This server had around
120 threads and
contrary to popular belief, that many threads is not only
feasible, they
server a purpose.

Pardon my rambling, seem to be a long way off the subject
of migrating to
64-bit CTime. Just pointing out why some of us have to get
"dirty". I still
have a group that thinks they can create a high
performance app in .NET using
Web Services and remoting. Have you ever looked into what
happens with a Web
Service call?

Don't get me wrong, .NET has its place as well as Web
Services. Just use the
right tool for the job - of course this means knowing the
capabilities of the
tool.