Altova Mailing List Archives>Archive Index >xml-dev Archive Home >Recent entries >Thread Prev - RE: [xml-dev] Is it time for the binary XML permathread to start up again? >Thread Next - RE: [xml-dev] Is it time for the binary XML permathread to start up again? RE: [xml-dev] Is it time for the binary XML permathread to start up again?To: <noah_mendelsohn@--.---.---> Date: 7/23/2007 9:10:00 AM > Thanks, but I think you missed my point. I assume that the reason people would use FI without gzip is mainly for speed. People use FI for good compactness without suffering a processing penalty as with gzip. > I'm asking, when they use FI+gzip as shown below to get that extra 15% in space compared to gzip FI by itself, am I right that they lose a lot of the speed advantage that FI gave them originally? I'm not saying this is bad. I'm suggesting: > > FI: good speed, moderate compression > gzip: very good compression, slow > FI + gzip: slightly better compression than gzip, slightly slower than gzip As an indication, gzip time can add 30%-500% to serialization time. In our measurements [fi serialization + gzip compression] is generally slower than [text serialization] but faster than [text + gzip]. Then again, if your FI doc returns high compactness your [fi + gzip] can be as fast as [text]. > Noah Mendelsohn Alexander | ||||||
| Company | Legal | Press | Partners | Careers | Sitemap | Contact Us | Altova Blog | Mobile | Full Site | |||
|
