I finished a purchasing application where I designed my own paging system. It uses remoting which causes a huge performance loss on huge transfers (server hits 100% cpu load when it serializes the stream). I currently have the app fetching a record each time the user hits next. Just wondering if I should cause each user to eat up more memory and cache more records, or if I should hit the dbase more often. So basically it boils down to my app being a memory hog or sql server getting more hits. I went with more hits because there won't be many users for the app (5 at the most?). Just wondering what others' opinions were. Thanks.

You should always limit the amount of time spend in the slowest part of the process (well, that's obvious of course, but often this is overlooked ).

Serialization -> network transport over a wire -> deserialization is often the bottleneck, but it depends on the network speed. For example, are you on a gigabit ethernet connection, the network is faster than most harddisks can deliver data. This means that the bottleneck can be in the database instead.

Nevertheless, serialization and deserialization is not the fastest way of handling data. It's often slower than expected and especially if the datablocks are becoming huge. that said, for paging through data, the user is often not interested in 1000's of rows so if you have a paging system which shows 20-50 entities at a time, this will never be slow.

Thanks for the fast reply. I wasn't prepared for the remoting server to reach such CPU usage with only 5,000 or so records. I was prepared for the memory consumption on the client, so luckily I prepared for that with the orders (with the paging). I didn't page other portions such as vendors, and this turned out devestating later so I was forced to implement the paging in that as well. Thanks again. LLBL rocks