DonationCoder.com Software > N.A.N.Y. 2019

NANY 2019 - Windows App - Process Watcher

<< < (3/8) > >>

mouser:
Would it be feasible to (have an option to) reverse that, so that latest entries appear first?
--- End quote ---

No, because appending to the file is fast and reliable and the opposite is not true.

But I think the real solution here is eventually a nice (standalone) gui tool for more nicely viewing the contents of the file in a proper grid or something.  That will wait until I figure out the final kind of data to be saved.  But yeah, the solution to more pleasant viewing of the data gathered is a gui tool for it.

mouser:
Also, I think that using a standard type log for this would make it useful, i.e. csv or tab-separated so that the data could be processed easily.
--- End quote ---

You are right, I'm open to suggestions.. If you look at the format I'm using now, it's basically JSON (though not 100% valid json since I don't properly escape the strings).  I do think I would like to save in a format that would make it easier for someone else write a GUI tool to browse history.

But first I have to figure out what kind of information I will be logging.  Right now both of these data files are just logging the occasional process entry so it's not that important.  But if I start to log performance data constantly for every running process then it will be important to use a data format that is compact.

Ath:
Well, about that file-format: I was going to ask you to use real JSON, as the current content isn't quite readable using standard tools/libraries, but also seeing your remark about compact/heaps of data, I'd suggest to switch to CSV, as that's usually the most compact and usable for non-complex data like this (unless you want to put the performance/usage data inside the JSON object ofcourse...).

Continuing on the subject of including performance/usage data: Using (structured) JSON storage would require you to rewrite the entire file when updating a single performance item, so the policy of 'only appending' isn't going to work.
I've suggested (reply #3) to create a file-per-exe for the performance/usage data, and when using CSV that would be a feasible and fast solution, including append-only. It will generate a lot of files though, so a configurable log directory would be nice to have.

I might even be tempted into creating a GUI for this data, but you'd have to have the storage format finalized first.

mouser:
There are 2 kinds of files that this program will be writing -- those where speed and space is important and those where it is not.

These files are not speed/space sensitive because they only get written out occasionally.. So JSON is a reasonable choice.  I'll bit the bullet and make them fully json compliant.

Then there may be some files that are sensitive to speed and size, like cpu and memory use files which are updated very frequently.  For those I'll have to decide on some other format, or even use a proper database.

Ath:
That sounds like a very solid path :Thmbsup:

Navigation

[0] Message Index

[#] Next page

[*] Previous page