Re: Compress timing with different data types
- To: mathgroup at smc.vnet.net
- Subject: [mg97785] Re: Compress timing with different data types
- From: Yves Klett <yves.klett at googlemail.com>
- Date: Sat, 21 Mar 2009 05:20:03 -0500 (EST)
- References: <gpsr4o$mh9$1@smc.vnet.net> <gpvh67$gp4$1@smc.vnet.net>
Mark, interesting - so there might be some noticeable platform/machine dependency. It is true, both sets are compressed nearly to the same size ByteCount /@ {cd, cl} {30520, 30848} and better compression rate should take more time. In fact, for some similar expressions the compression rate is quite high (say about 20:1). The drawback here is the nonlinear time scaling that makes Compress extremely slow for large expressions (the one here is just a toy example, although I work with large Line sets that for historical (pre-6) reasons cannot be replaced with their multi-argument equivalent). Timings on other systems/machines would be interesting. Regards, Yves mark mcclure schrieb: > On Mar 19, 3:10 am, Yves Klett <yves.kl... at googlemail.com> wrote: >> I noticed that the speed of Compress is very much dependent on >> the type of data that is compressed: >> ... >> compressing an expression only containing lists and numbers is about >> 60 times faster than compressing an expression containing Line >> statements. And the difference gets worse the larger the expression >> becomes... >> >> Does anyone have experience and/or a workaround with that >> behaviour (6.03 & 7.01 on WinXP)? > > Running your code in both V6.0.3 and V7.0.1 on my Mac laptop, I get > speed ratios of more like 6 or 7, rather than 60. Of course, I wouldn't > expect Compress to accomplish anything with an array of random > numbers, while an expression containing many copies of a Line > primitve would be compressed a lot. Perhaps this has something to > do with it. > > Incidentally, there's no reason to map Line onto data. That is > Line[data] is perfectly valid and renders faster than Line /@ data. > > Mark McClure > >