> The current approach has got to be quite inefficient. The problem I've got > is that I can't come up with anything other than a WAG as to how much > faster it will be.
It's been some time since I tested out size v. speed relationships in a similar setup. And, of course, it depends on your hardware, network, etc. But, when I last tested it, the size of the download correlated pretty exactly with the download time. I mean end-to-end. So, the overhead on compression paid for itself nearly instantly. (The overhead proved to be small.) 30% smaller payload, 30% less time required to download it. Like you, I wasn't clear what the breakeven point was for the expense of compression. I couldn't find a place where compression was a bad bet. Assuming I'm on track with what you guys are talking about and haven't wandered off into the woods again... ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
