Fix Inefficient String Encoding

[jacobadenbaum]

The code for constructing List(v::Vector{String}) is extremely slow, causing problems when writing Feather files of dataframes that are string heavy (for instance, it took me 770s to write a 3.2GB file with a large number of address fields, whereas python can write the same file in 12s). It looks like the problem comes from the code that encodes the strings as vectors of UInt8.

I played around with it, and it looks like you can get nearly a 20X speedup by writing a specialized method to handle vectors of strings as in this PR:

julia> using Arrow, BenchmarkTools
julia> x = repeat(["a", "b", "c"].^10, 5_000_000);
# Before this PR
julia> @btime arrowformat($x)
  8.794 s (45016393 allocations: 69.95 GiB)
# After this PR
julia> @btime arrowformat($x)
  463.789 ms (13 allocations: 400.54 MiB)

I'm not super familiar with the internals of string encodings, but this seems to work on my local machine (and passes all the tests). I've tried it out with Feather as well on some real world datasets, and everything seems to work properly.

[ExpandingMan]

That's extremely helpful, thanks! I must confess, when I wrote this I was much more concerned with deserialization than serialization, so I did not spend that much time benchmarking the serialization, perhaps not at all for strings (which is pretty much the only non-trivial case that this package now supports).

I have no idea why stupid travis is not triggering. I always have problems with it. It never triggers and I don't know why, it's extremely annoying. So, I have to try to figure that out before merging.

Also, be advised that I am in the process of doing a major re-write of this package to support the full standard and IPC metadata. There may be some regressions by the time I'm finished, but I will probably merge that into master quite a while before I tag it, so there will be ample opportunity to fix those. Things will become considerably trickier, because now I must support much more general cases, for example the underlying List object must be appropriate for both String and Vector (though List will work somewhat differently, as the underlying List will only return Vector objects from getindex operations, and there will be a wrapper AbstractVector which will have a getindex method which returns Strings).

Anyway, if I get too frustrated with travis, I will test this locally and then merge. Thanks.

[jacobadenbaum]

It looks like Travis did get triggered, but it just isn't hooking into the PR

[ExpandingMan]

Yes you are correct. If you have any ideas about how to get it to display, it would be much appreciated.

[ExpandingMan]

I see no reason to wait to merge this, so I'll do so now. Thanks again.