EPIJudge VS FlatBuffers

I don't know about Leetcode. But there is an off line test suite you can download for the problems of EPI (for Python, Java, and C++). https://github.com/adnanaziz/EPIJudge

Anyone still using Elements of Programming Interviews out there? I still do... As they don't support Go, I have implemented a Go version of their EPI Judge. This allows to check that a solution passes all the tests included by the authors in the original EPI Judge. Here it is, in case it can be of use to anyone preparing for interviews: https://github.com/stefantds/go-epi-judge (in case it helps, here you can also find my solutions to the problems from the book: https://github.com/stefantds/go-epi-solutions )

Both books are good, but I lean towards EPI as it has practice problems in the specific language you want.

I’ve done DSA problems from a book that has a companion repository with all the problems and it has a test_data/ directory with the test cases: https://github.com/adnanaziz/EPIJudge

I don't work at Cloudflare but follow their work and occasionally work on performance sensitive projects.

If I had to guess, they looked at the landscape a bit like I do and regarded Cap'n Proto, flatbuffers, SBE, etc. as being in one category apart from other data formats like Avro, protobuf, and the like.

So once you're committed to record'ish shaped (rather than columnar like Parquet) data that has an upfront parse time of zero (nominally, there could be marshalling if you transmogrify the field values on read), the list gets pretty short.

https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... goes into some of the trade-offs here.

Cap'n Proto was originally made for https://sandstorm.io/. That work (which Kenton has presumably done at Cloudflare since he's been employed there) eventually turned into Cloudflare workers.

Another consideration: https://github.com/google/flatbuffers/issues/2#issuecomment-...

Much more in the discussion of this particular issue onGitHub: flatbuffers:Reverse engineering #4258

Related but not Rust-specific: FlatBuffers, Cap'n Proto.

If json files are a concern because of space, you can always look into something like protobuffers or flatbuffers. But whatever you use, you should try to find a solution where you don't have to think about the actual serialization/deserialization of your objects, and can just concentrate on the data.

Or, as an alternative to protobuffers, there's also flatbuffers, which is lighter weight and needs less memory: https://google.github.io/flatbuffers/

As the title suggests, I am considering using Flatbuffers as a way to parse sensor data that has been stored in local datafiles. The project language is python.