Log files

Hi,

How do I prevent ReSharper v4 (v3) from writing to logfiles located in
../Local Settings/Temp/JetLogs ?

It seems to be a background task triggered every time a file is opened or
edited. A simple newline in a cs file triggers alot of writes to a logfile.

I have no use of such a log file and if it is for debug purposes, I should
be able to toggle it on-off.



19 comments
Comment actions Permalink

Hello,

The logging is unconditional and cannot be turned off.

Old log files are cleaned up automatically.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

You say that old logs get cleaned up. Can you detail the cleanup algorithm? I have logs from a week ago on my machine, taking up 55 MB.

I, too, looked with Process Monitor, and found a high percentage of disk IO was caused by your logging. I'm running on a laptop, and disk IO is at a premium.

Please consider using a more efficient logging mechanism such as ETW.

At the very least, you should cycle the log files more frequently. You appear to create one log per VS session, and I stay in VS for days sometimes. A 10MB ReSharper log is typical.

Thanks,
John

0
Comment actions Permalink

I second that. I noticed using Process Monitor that at least half of the disk I/O is caused by R# writing to log files. The log files easily take up 100 MB. We have rather slow and small disks here so I cannot waste any time / place for log files which are never needed. Please put a checkbox somewhere in your options to disable extensive logging.

0
Comment actions Permalink

I agree, it would be great to be able to turn them off.

0
Comment actions Permalink

I too agree that having the option is better.

0
Comment actions Permalink

I agree too.

But didn't we all ask for this about 3 weeks ago?

Will

0
Comment actions Permalink

Hello Will,

We are actively developing ReSharper and sometimes add more logging to check
when and how things come to the dark side. When we will be preparing release
builds, we will remove excessive logging.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


WD> I agree too.
WD>
WD> But didn't we all ask for this about 3 weeks ago?
WD>
WD> Will
WD>


0
Comment actions Permalink

ConditionalAttribute is your friend.

"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:76a2bd0b153d498ca5d9c0f55b1fa@news.intellij.net...

Hello Will,

>

We are actively developing ReSharper and sometimes add more logging to
check when and how things come to the dark side. When we will be preparing
release builds, we will remove excessive logging.
Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>

WD> I agree too.
WD> WD> But didn't we all ask for this about 3 weeks ago?
WD> WD> Will
WD>


0
Comment actions Permalink

Hello Mike,

Thank you, we know about this attribute. But the problem is that when something
goes wrong with ReSharper on YOUR computer, in already installed nightly
build, which is built in release configuration, we may want logs to see what
get wrong. It's too late to enable logging, or changing logging severity,
or something else. What we have are just existing logs, and they'd better
have more info than less.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


MS> ConditionalAttribute is your friend.
MS>
MS> "Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
MS> news:76a2bd0b153d498ca5d9c0f55b1fa@news.intellij.net...
MS>
>> Hello Will,
>>
>> We are actively developing ReSharper and sometimes add more logging
>> to
>> check when and how things come to the dark side. When we will be
>> preparing
>> release builds, we will remove excessive logging.
>> Sincerely,
>> Ilya Ryzhenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>> WD> I agree too.
>> WD> WD> But didn't we all ask for this about 3 weeks ago?
>> WD> WD> Will
>> WD>


0
Comment actions Permalink

Indeed. But using conditional debugging allows you to disable excess
logging in certain build configurations by removing the requisite #define
statements. Thus you can push out your official release versions with
minimal logging while keeping detailed logging in your EAP and nightly
builds (without removing any code, making unecessary logging calls, or
pushing string data onto the stack for a method like Logger.WriteDebug that
will not perform any actual work when that logging level is disabled).

Then again, I suppose I should give you guys more credit and assume that
you're doing this already ;).

Cheers,
Mike

"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:76a2bd0b153dac8ca5da5683f8eb6@news.intellij.net...

Hello Mike,

>

Thank you, we know about this attribute. But the problem is that when
something goes wrong with ReSharper on YOUR computer, in already installed
nightly build, which is built in release configuration, we may want logs
to see what get wrong. It's too late to enable logging, or changing
logging severity, or something else. What we have are just existing logs,
and they'd better have more info than less.

>

Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>

MS> ConditionalAttribute is your friend.
MS> MS> "Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
MS> news:76a2bd0b153d498ca5d9c0f55b1fa@news.intellij.net...
MS>

>>> Hello Will,
>>>
>>> We are actively developing ReSharper and sometimes add more logging
>>> to
>>> check when and how things come to the dark side. When we will be
>>> preparing
>>> release builds, we will remove excessive logging.
>>> Sincerely,
>>> Ilya Ryzhenkov
>>> JetBrains, Inc
>>> http://www.jetbrains.com
>>> "Develop with pleasure!"
>>> WD> I agree too.
>>> WD> WD> But didn't we all ask for this about 3 weeks ago?
>>> WD> WD> Will
>>> WD>
>


0
Comment actions Permalink

Ilya,

I agree with you that you must have logging ability in released builds. I recommend you consider the type of functionality in the Enterprise Library 3.1, which allows logging to be turned on or off at runtime, or turned on for particular categories or priorities, or can be redirected to different locations and logging strategies. This would allow you to use a rolling log file, or to output to a SQLEXPRESS database, or whatever you need, all configured at runtime. It also integrates with their Exception Handling block.

If you don't want to go as far as Enterprise Library, you can still do a lot with System.Diagnostics.TraceSource, etc.

0
Comment actions Permalink

You guys are complaining?

My log file was 16GB (yes that is 16 Gigabytes) just after 1 day of running the new build!

0
Comment actions Permalink

Hi,

After reading this thread I had to check my logs, too (build 763). Yesterday's logs were ~1,5 GB, the day before ~1 GB, so indeed R# is quite "chatty". On the other hand it isn't called EAP for nothing and we all know that logging can be a useful tool to track down errors.

Still, when I look into the logs they seem to contain a lot of strange messages, like hundreds over hundreds lines stating
Thread:1: Queueing “<NULL>”.
or
Thread:1: Executing “”.

I think there is something going wrong when formatting the log messages. As a final note: log what you think is useful, especially in the EAP builds. But keep in mind that excessive disk I/O adversely affect system performance.

Regards,
Andre

P.S.:
Don't say the JetBrainers have no humor:
Thread:1: Thread “”:1 pwned.

0
Comment actions Permalink

Yeah, me also it is full of these null and 0.

I think these could be turned off safely for the EAP :)

0
Comment actions Permalink

On the other hand it isn't called EAP for nothing and we all know that logging can be a useful tool to track down errors.


Just to be clear, I'm getting my log file issue with the released 3.1 version, not with the 4.0 EAP. So it may be worse with the EAP, but it's pretty bad with the released version.

0
Comment actions Permalink

I've also got over a 1G of logs for the last few days - there's one file in there which is >770M on its own.

I understand why logging might suit JB, but this is just not an appropriate use of your customers' machines, or your EAPers' good will.

I know no software author ever feels like this about his own products, but try not to forget that running R# is not the only thing we're trying to do with our computers, and polite sharing of the computer/OS by all vendors is much appreciated!

And as the the OP has had to reappear to point out, this is not just an EAP problem - to me this indicates a carelessness towards playing nicely with everyone else... Even 'idle' CPU activity is expensive, background disk thrashing is hideous.

0
Comment actions Permalink

I have just installed version 3.1 and I would find usefull to switch logging off. Is there any way how to do it ?

0
Comment actions Permalink

Hello,

I have just installed version 3.1 and I would find usefull to switch
logging off. Is there any way how to do it ?


You can disable R# logging externally, and that won't harm ReSharper.

By the 4.0 release, we'll make sure that the default logging is minimal.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Could you please detail how I can achieve this please. I am running R# 3.1 and would like to see an end to the constant disk IO being generated due to Resharper logging. This is having a performance impact and interferes with profiling as well. So any tips would be much appreciated

0

Please sign in to leave a comment.