MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

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
> 
> 


  • Prev by Date: Re: Output from a Dynamic Module
  • Next by Date: Re: Re: Re: Using Mathematica notebooks in presentations?
  • Previous by thread: Re: Compress timing with different data types
  • Next by thread: Re: Compress timing with different data types