2
\$\begingroup\$

So I'm using Unity's profiler to help debug some of my code in the standalone. I've got it running smoothly, and writing all it's data to a .data file which I can read.

However, the binary file Unity creates for profiler information gets quite huge very quickly. I'm hoping to get past this by writing the profiler data log to a zip archive. I have dotnetzip installed, and can add files to a zip archive.

What I'm trying to figure out is how I could possibly either write the profiler data log directly to the zip archive, or write the profiler binary data to a variable of some sort which I could store in a stream and write to the zip archive on quit. This way I won't ever have to have the large file on the user's drive.

Another option would be to continuously write the binary data to the log on the drive, then get the binary info from that log, write it to a stream, put it in to a zip archive, then delete the log. However I'd have to do this every few seconds, and that may get slightly process intensive.

Improve this question
\$\endgroup\$
5
  • \$\begingroup\$ Unless the files being generated are hundreds of gigabytes, for the sake of development this seems rather unnecessary. You would have to write a system that streamlines the compression of data as it is written to a file. Also, whichever tool you need to analyze the data would have to uncompress it, or you uncompress it manually yourself before hand. Really it just makes for much slower iteration time. You mention large files on the users drive? Your customer should never be outputting profiler logs, as they should be running optimized release copies of the game. \$\endgroup\$
    – Evan
    Sep 20 '13 at 19:45
  • \$\begingroup\$ The files are generating roughly 1 gigabyte per minute of ingame time. And the tool can easily uncompress it. This is for alpha testing purely, I'd never have an end customer outputting profiler logs. The whole reason for this is so that the end customer CAN have an optimized copy of the game. This is a very common way development studios test their games. I'm surprised you haven't heard of alpha testing \$\endgroup\$
    – Timothy Williams
    Sep 20 '13 at 22:14
  • \$\begingroup\$ I understand the desired results, and I'm not sure how my comment is any indication of my knowledge of software development cycles. Either way, my experience with profiling games has never lead me to desire continuous high volume output for any extended period of time. Resource monitoring, and real-time profiling has yielded sufficient evidence to narrow down the focus for high volume profiling. If this is necessary though, time versus storage, the traditional trade off. \$\endgroup\$
    – Evan
    Sep 20 '13 at 23:30
  • \$\begingroup\$ I'm most likely either going to use a time versus storage method, or work out an archiving method. I'm thinking of saving the binary data to a stream which I can then write to a compressed archive. Although there are downsides to having a stream get too large. \$\endgroup\$
    – Timothy Williams
    Sep 22 '13 at 13:41
  • \$\begingroup\$ I know this is old, but how are you reading the binary data file? Are you able to provide any source for this, if you still have it? \$\endgroup\$
    – S.Richmond
    Sep 3 '15 at 13:28
2
\$\begingroup\$

So I figured out how to do this efficiently. What I do is every X minutes write all the data to a stream and delete the data file. This causes the data to not take up so much disc space. Then on application quit I write all that data from the stream to a compressed archive. I end up getting roughly 1 megabyte a minute from the Profiler, rather than 1 gigabyte.

Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.