4 ms·
Those two are not equivalent. Actually, I'm surprised that people didn't find the first one harder: I've had log files that were larger than RAM before (mainly
by TheLoneWolfling 11y ago
Those two are not equivalent. Actually, I'm surprised that people didn't find the first one harder: I've had log files that were larger than RAM before (mainly due to overzealous logging).
- userbinator 11y agoIf the first thing your solution does is attempt to read the entire file into memory, then you probably failed the test. The same goes for trying to read an entire line into memory, however long it may be - this is a problem that can be solved with an essentially constant space of around a dozen bytes.
- kstrauser 11y agoExactly! I've been asked the followup question: "now assume that you have 8 petabytes of log files to search", which leads into distributed computing, realtime vs on-demand collection, eventually consistent counters, the pros and cons of sampling vs exact counts, and so on. The unbounded form of that question can be astonishingly hard, and for the kinds of jobs I'd be interviewing for I'd expect the challenging next questions. I'd still answer along the lines of "for a quick solution I'd grep for the error level and count the number of lines, but that's not scalable".
- TheLoneWolfling 11y agoDitto. (Also, no need to pipe + count: `grep -c` works.) Also, problem with sampling: you oversample long lines. I'm not actually sure if there is any way to count probabilistically that doesn't. I suppose if you had some prior of how long the types were you may be able to do better, but in general, good luck.