Here's an interesting complement to Edmund's answer. It's not always the case that the ByteArray form will be more compact. DocFind is just a table of reflinks I use for doc searching.

In[155]:= bs = BinarySerialize@DocFind[]; // RepeatedTiming Out[155]= {1.8, Null} In[156]:= cp = Compress@DocFind[]; // RepeatedTiming Out[156]= {1.74, Null} In[157]:= bs // ByteCount Out[157]= 3027593 In[158]:= cp // ByteCount Out[158]= 233104 

On the other hand it's minimally faster to BinaryDeserialize:

In[159]:= Uncompress@cp; // RepeatedTiming Out[159]= {0.34, Null} In[160]:= BinaryDeserialize@bs; // RepeatedTiming Out[160]= {0.30, Null} 

If we use a much larger input we get a much more interesting result, though:

In[145]:= bs2 = BinarySerialize@Range[10000000]; // AbsoluteTiming Out[145]= {0.16928, Null} In[153]:= cp2 = Compress@Range[10000000]; // AbsoluteTiming Out[153]= {4.92081, Null} 

My intuition would suggest that BinarySerialize should almost always be as fast or faster than Compress but I'd be interested to be proven wrong.

Here the serialized version is much more compact:

In[161]:= bs2 // ByteCount Out[161]= 80000104 In[162]:= bs3 // ByteCount Out[162]= 31276128 

And it's so much faster to use BinaryDeserialize here than Uncompress:

In[163]:= BinaryDeserialize@bs2; // RepeatedTiming Out[163]= {0.13, Null} In[164]:= Uncompress@cp2; // AbsoluteTiming Out[164]= {29.8372, Null} 

Again, because it's a byte format, my intuition would suggest Binary* will be faster and often more compact than a compressed string.

###Update: yode confirmed that it is platform independent

On the other hand, since it's a byte format I would also believe it's platform dependent -- i.e., I can't take my serialized ByteArray and mail it to you and expect it to work if we have different operating systems/architecture, the same way I can't expect that of .mx files.

Here's an interesting complement to Edmund's answer. It's not always the case that the ByteArray form will be more compact. DocFind is just a table of reflinks I use for doc searching.

In[155]:= bs = BinarySerialize@DocFind[]; // RepeatedTiming Out[155]= {1.8, Null} In[156]:= cp = Compress@DocFind[]; // RepeatedTiming Out[156]= {1.74, Null} In[157]:= bs // ByteCount Out[157]= 3027593 In[158]:= cp // ByteCount Out[158]= 233104 

On the other hand it's minimally faster to BinaryDeserialize:

In[159]:= Uncompress@cp; // RepeatedTiming Out[159]= {0.34, Null} In[160]:= BinaryDeserialize@bs; // RepeatedTiming Out[160]= {0.30, Null} 

If we use a much larger input we get a much more interesting result, though:

In[145]:= bs2 = BinarySerialize@Range[10000000]; // AbsoluteTiming Out[145]= {0.16928, Null} In[153]:= cp2 = Compress@Range[10000000]; // AbsoluteTiming Out[153]= {4.92081, Null} 

My intuition would suggest that BinarySerialize should almost always be as fast or faster than Compress but I'd be interested to be proven wrong.

Here the serialized version is much more compact:

In[161]:= bs2 // ByteCount Out[161]= 80000104 In[162]:= bs3 // ByteCount Out[162]= 31276128 

And it's so much faster to use BinaryDeserialize here than Uncompress:

In[163]:= BinaryDeserialize@bs2; // RepeatedTiming Out[163]= {0.13, Null} In[164]:= Uncompress@cp2; // AbsoluteTiming Out[164]= {29.8372, Null} 

Again, because it's a byte format, my intuition would suggest Binary* will be faster and often more compact than a compressed string.

Update: yode confirmed that it is platform independent

On the other hand, since it's a byte format I would also believe it's platform dependent -- i.e., I can't take my serialized ByteArray and mail it to you and expect it to work if we have different operating systems/architecture, the same way I can't expect that of .mx files.

Here's an interesting complement to Edmund's answer. It's not always the case that the ByteArray form will be more compact. DocFind is just a table of reflinks I use for doc searching.

In[155]:= bs = BinarySerialize@DocFind[]; // RepeatedTiming Out[155]= {1.8, Null} In[156]:= cp = Compress@DocFind[]; // RepeatedTiming Out[156]= {1.74, Null} In[157]:= bs // ByteCount Out[157]= 3027593 In[158]:= cp // ByteCount Out[158]= 233104 

On the other hand it's minimally faster to BinaryDeserialize:

In[159]:= Uncompress@cp; // RepeatedTiming Out[159]= {0.34, Null} In[160]:= BinaryDeserialize@bs; // RepeatedTiming Out[160]= {0.30, Null} 

If we use a much larger input we get a much more interesting result, though:

In[145]:= bs2 = BinarySerialize@Range[10000000]; // AbsoluteTiming Out[145]= {0.16928, Null} In[153]:= cp2 = Compress@Range[10000000]; // AbsoluteTiming Out[153]= {4.92081, Null} 

My intuition would suggest that BinarySerialize should almost always be as fast or faster than Compress but I'd be interested to be proven wrong.

Here the serialized version is much more compact:

In[161]:= bs2 // ByteCount Out[161]= 80000104 In[162]:= bs3 // ByteCount Out[162]= 31276128 

And it's so much faster to use BinaryDeserialize here than Uncompress:

In[163]:= BinaryDeserialize@bs2; // RepeatedTiming Out[163]= {0.13, Null} In[164]:= Uncompress@cp2; // AbsoluteTiming Out[164]= {29.8372, Null} 

Again, because it's a byte format, my intuition would suggest Binary* will be faster and often more compact than a compressed string.

On the other hand, since it's a byte format I would also believe it's platform dependent -- i.e., I can't take my serialized ByteArray and mail it to you and expect it to work if we have different operating systems/architecture, the same way I can't expect that of .mx files.

Here's an interesting complement to Edmund's answer. It's not always the case that the ByteArray form will be more compact. DocFind is just a table of reflinks I use for doc searching.

In[155]:= bs = BinarySerialize@DocFind[]; // RepeatedTiming Out[155]= {1.8, Null} In[156]:= cp = Compress@DocFind[]; // RepeatedTiming Out[156]= {1.74, Null} In[157]:= bs // ByteCount Out[157]= 3027593 In[158]:= cp // ByteCount Out[158]= 233104 

On the other hand it's minimally faster to BinaryDeserialize:

In[159]:= Uncompress@cp; // RepeatedTiming Out[159]= {0.34, Null} In[160]:= BinaryDeserialize@bs; // RepeatedTiming Out[160]= {0.30, Null} 

If we use a much larger input we get a much more interesting result, though:

In[145]:= bs2 = BinarySerialize@Range[10000000]; // AbsoluteTiming Out[145]= {0.16928, Null} In[153]:= cp2 = Compress@Range[10000000]; // AbsoluteTiming Out[153]= {4.92081, Null} 

My intuition would suggest that BinarySerialize should almost always be as fast or faster than Compress but I'd be interested to be proven wrong.

Here the serialized version is much more compact:

In[161]:= bs2 // ByteCount Out[161]= 80000104 In[162]:= bs3 // ByteCount Out[162]= 31276128 

And it's so much faster to use BinaryDeserialize here than Uncompress:

In[163]:= BinaryDeserialize@bs2; // RepeatedTiming Out[163]= {0.13, Null} In[164]:= Uncompress@cp2; // AbsoluteTiming Out[164]= {29.8372, Null} 

Again, because it's a byte format, my intuition would suggest Binary* will be faster and often more compact than a compressed string.

###Update: yode confirmed that it is platform independent

On the other hand, since it's a byte format I would also believe it's platform dependent -- i.e., I can't take my serialized ByteArray and mail it to you and expect it to work if we have different operating systems/architecture, the same way I can't expect that of .mx files.