Toparvion
commented
5 years ago @gamefundas You are exactly right. From the very first drafts of AnaLog, browser memory consumption was one of the main concerns to deal with. It is clear that every single log line "weights" a lot more when represented as a DOM element. That is why AnaLog indeed restricts the "depth" of its console buffer. Though there is a couple of subtle concerns with it:
- When working with composite logs, the client (web browser application) operates in terms of log records but not log lines. The difference is most observable on stacktraces: they are single records each consisting of dozens of lines. It means that the console buffer depth must also be measured in records which is quite inaccurate measure. Nevertheless it deserves to have a place because cutting on records gives smoother user experience which lead us to point 2:
- It is not enough to have a single "console depth threshold" parameter because after reaching it, the renderer would have to cut off old records on every appending a new one. It would cause the log to "tremble" in console. To avoid this, AnaLog cuts off the old records in bunches making the actual number of records to turn around the buffer depth threshold value.
Both values - buffer depth threshold and bunch size - are configurable parameters but due to their pure front-end nature there are not exposed in main configuration file yet (´application.properties´). Instead, they are located in config.js which is not easely accessible for administrator.
And yes, log downloading feature is supposed to be an alternative to working with whole logs in browser. Except that, the feature tries to fill the gap of absence of ability to "rewind" a log toward its beginning. At the moment the feature is available for plain logs only (both remote and local ones) but it is quite clear how to extend it for other log sources.
gamefundas
I haven't tested the UI tailing very large logs files but whats the implementation around handling huge files. Does Analog retain everything that it has tailed so far in the browser DOM or it maintains some kind of buffer window and anything outside of this is chunked?
From the user experience standpoint, this would mean one cant indefinitely scroll back in time to view log contents, some information will be lost as the log trail grows. This is perfectly fine as there is always an option to download the file if needed. However from the efficiency standpoint it will be important to restrict the view to a buffer limit.