Slow performance with large files

Alright - what I'm about to say is going to make you cry - but it is what I
ahve to work with so bear with me.

I'm now working with a codebase in which one particular file contains nearly
10,000 lines of code.

Stop. Deep breath.

OK - so. Resharper (not unexpectedly) takes FOREVER to re-analyze the file
whenever I make a change. I'm trying to examine options for improving this.

Splitting this class up into smaller units is not practical at this point as
it would involve changing a large amount of other code which uses it.

I was wondering if partial classes would help. I could split the code into
smaller individual files. By using partial classes, I solve the issue of
having to change existing code which uses this. My initial test with this
shows that Resharper did not improve with this. I moved a small section out
into a partial class and the performance was just as bad. I assume
Resharper is completely re-creating the entire class structure when
analyzing?

I may just have to turn resharper off for this, simply for the sake of my
sanity. Any suggestions on what could be done to improve resharper
performance?

--
Adam Clauss



11 comments
Comment actions Permalink

Splitting such huge clas into the partial one won't help. since ReSharper
have to inspect through all parts. Otherwise nearlyy all advanced
inspections would be impossible.

There is shortcut to disable resharper background analysis for the specific
file: Ctrl-8

We are working to improve the performance of the background analysis, but no
dramatical improvements can be expected

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Adam Clauss" <cabadam@no@spam.com> wrote in message
news:dvn3na$pl$1@is.intellij.net...

Alright - what I'm about to say is going to make you cry - but it is what
I ahve to work with so bear with me.

>

I'm now working with a codebase in which one particular file contains
nearly 10,000 lines of code.

>

Stop. Deep breath.

>

OK - so. Resharper (not unexpectedly) takes FOREVER to re-analyze the
file whenever I make a change. I'm trying to examine options for
improving this.

>

Splitting this class up into smaller units is not practical at this point
as it would involve changing a large amount of other code which uses it.

>

I was wondering if partial classes would help. I could split the code
into smaller individual files. By using partial classes, I solve the
issue of having to change existing code which uses this. My initial test
with this shows that Resharper did not improve with this. I moved a small
section out into a partial class and the performance was just as bad. I
assume Resharper is completely re-creating the entire class structure when
analyzing?

>

I may just have to turn resharper off for this, simply for the sake of my
sanity. Any suggestions on what could be done to improve resharper
performance?

>

--
Adam Clauss

>
>



0
Comment actions Permalink

If you have a class with so much lines, i think you have a major design
problem...
A class should never be so much complex...


"Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> a écrit dans
le message de news: dvo72p$ua$1@is.intellij.net...

Splitting such huge clas into the partial one won't help. since ReSharper
have to inspect through all parts. Otherwise nearlyy all advanced
inspections would be impossible.

>

There is shortcut to disable resharper background analysis for the
specific file: Ctrl-8

>

We are working to improve the performance of the background analysis, but
no dramatical improvements can be expected

>

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Adam Clauss" <cabadam@no@spam.com> wrote in message
news:dvn3na$pl$1@is.intellij.net...

>> Alright - what I'm about to say is going to make you cry - but it is what
>> I ahve to work with so bear with me.
>>
>> I'm now working with a codebase in which one particular file contains
>> nearly 10,000 lines of code.
>>
>> Stop. Deep breath.
>>
>> OK - so. Resharper (not unexpectedly) takes FOREVER to re-analyze the
>> file whenever I make a change. I'm trying to examine options for
>> improving this.
>>
>> Splitting this class up into smaller units is not practical at this point
>> as it would involve changing a large amount of other code which uses it.
>>
>> I was wondering if partial classes would help. I could split the code
>> into smaller individual files. By using partial classes, I solve the
>> issue of having to change existing code which uses this. My initial test
>> with this shows that Resharper did not improve with this. I moved a
>> small section out into a partial class and the performance was just as
>> bad. I assume Resharper is completely re-creating the entire class
>> structure when analyzing?
>>
>> I may just have to turn resharper off for this, simply for the sake of my
>> sanity. Any suggestions on what could be done to improve resharper
>> performance?
>>
>> --
>> Adam Clauss
>>
>>
>>
>



0
Comment actions Permalink

Hello John,

If you have a class with so much lines, i think you have a major
design
problem...
A class should never be so much complex...
"Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> a écrit
dans le message de news: dvo72p$ua$1@is.intellij.net...


Unfortunately, many auto-generated files tend to be that big and even more.

Thanks,
Andrey Simanovsky


1
Comment actions Permalink

Then if a class is autogenerated, you should not edit it.
You should extend it in case of regeneration.
And it's not because it is autogenerated that it can be badly designed...

But anyway, users designs are not your concerns, you have to do with.
Good luck JetBrains team! :)

"Andrey Simanovsky (JetBrains)" <ands@intellij.com> a écrit dans le message
de news: c8a8a15d106608c81b0a5893e709@news.intellij.net...

Hello John,

>
>> If you have a class with so much lines, i think you have a major
>> design
>> problem...
>> A class should never be so much complex...
>> "Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> a écrit
>> dans le message de news: dvo72p$ua$1@is.intellij.net...
>>
>

Unfortunately, many auto-generated files tend to be that big and even
more.

>

Thanks,
Andrey Simanovsky

>



-1
Comment actions Permalink

Hello John,

Extending it or making it partial, R# still needs to analyze it anyway. So
I think it's still expensive. Have to wish Jetbrains the best in finding
a way to improve the performance.

Then if a class is autogenerated, you should not edit it.
You should extend it in case of regeneration.
And it's not because it is autogenerated that it can be badly
designed...
But anyway, users designs are not your concerns, you have to do with.
Good luck JetBrains team! :)

"Andrey Simanovsky (JetBrains)" <ands@intellij.com> a écrit dans le
message de news: c8a8a15d106608c81b0a5893e709@news.intellij.net...

>> Hello John,
>>
>>> If you have a class with so much lines, i think you have a major
>>> design
>>> problem...
>>> A class should never be so much complex...
>>> "Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> a
>>> écrit
>>> dans le message de news: dvo72p$ua$1@is.intellij.net...
>> Unfortunately, many auto-generated files tend to be that big and even
>> more.
>>
>> Thanks,
>> Andrey Simanovsky


0
Comment actions Permalink

A point for you! :)

I do not forget that resharper is coded in c#...
I don't think i could do something so fast, so about doing something
faster...

Once again, good luck jetbrains team!

"Nat" <nat@do-not-spam.org> a écrit dans le message de news:
a4b668e749fa8c81ac9e4295a7e@news.intellij.net...

Hello John,

>

Extending it or making it partial, R# still needs to analyze it anyway. So
I think it's still expensive. Have to wish Jetbrains the best in finding a
way to improve the performance.

>
>> Then if a class is autogenerated, you should not edit it.
>> You should extend it in case of regeneration.
>> And it's not because it is autogenerated that it can be badly
>> designed...
>> But anyway, users designs are not your concerns, you have to do with.
>> Good luck JetBrains team! :)
>>
>> "Andrey Simanovsky (JetBrains)" <ands@intellij.com> a écrit dans le
>> message de news: c8a8a15d106608c81b0a5893e709@news.intellij.net...
>>
>>> Hello John,
>>>
>>>> If you have a class with so much lines, i think you have a major
>>>> design
>>>> problem...
>>>> A class should never be so much complex...
>>>> "Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> a
>>>> écrit
>>>> dans le message de news: dvo72p$ua$1@is.intellij.net...
>>> Unfortunately, many auto-generated files tend to be that big and even
>>> more.
>>>
>>> Thanks,
>>> Andrey Simanovsky
>



0
Comment actions Permalink

"john" <nospam@you.can> wrote in message
news:dvonci$6c2$1@is.intellij.net...

If you have a class with so much lines, i think you have a major design
problem...
A class should never be so much complex...


No argument hehe... unfortunately, it is what it is, and I do not think I
can afford to re-structure 10,000 lines of code (and all the code that uses
it) within my current time constraint.

--
Adam Clauss


0
Comment actions Permalink

"Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> wrote in
message news:dvo72p$ua$1@is.intellij.net...

Splitting such huge clas into the partial one won't help. since ReSharper
have to inspect through all parts. Otherwise nearlyy all advanced
inspections would be impossible.


Ah, I wasn't sure if R# would be able to 'cache' the other parts of the
class which did not change, to improve that speed.

There is shortcut to disable resharper background analysis for the
specific file: Ctrl-8


Now THAT will be useful. How long is that effective for? Re-opening the
solution?

We are working to improve the performance of the background analysis, but
no dramatical improvements can be expected


I understand.

Thanks for your help!

--
Adam Clauss


0
Comment actions Permalink

Not everything could be cached.....

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Adam Clauss" <cabadam@no@spam.com> wrote in message
news:dvp1ed$919$1@is.intellij.net...

"Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> wrote in
message news:dvo72p$ua$1@is.intellij.net...

>> Splitting such huge clas into the partial one won't help. since ReSharper
>> have to inspect through all parts. Otherwise nearlyy all advanced
>> inspections would be impossible.
>

Ah, I wasn't sure if R# would be able to 'cache' the other parts of the
class which did not change, to improve that speed.

>
>> There is shortcut to disable resharper background analysis for the
>> specific file: Ctrl-8
>

Now THAT will be useful. How long is that effective for? Re-opening the
solution?

>
>> We are working to improve the performance of the background analysis, but
>> no dramatical improvements can be expected
>

I understand.

>

Thanks for your help!

>

--
Adam Clauss



0
Comment actions Permalink

Not everything could be cached.....


"i think you have a major design problem..."
(c) john.

As begun, what do you think about regions in code?
You think its orthogonal to root from any leaf of code-tree.

Look at your File Structure window.

So, when you fail your tree-based reverse-engineering of
code - we can be assured, that you at serious troubles with
caching at least.

Excuse, but we do not see that you imagine treelike structure
of parsed code.

Good prepared trees - its a dream for cashing! :)
Its only current leaf and recursive calls in one function
to recursive leafses with a setting a flag "outdate".
And in the second transaction - recalculation of outdated.
Its a Bible.

Shure, not everything could be cached, but in right
reverse-engeneered tree its not depend on file size
or class size - its only depends on recursive nodes
vectors count.

Special cases with renaming can be simple fixed at
parsing of error, before you offer a way to fix it by Alt-Enter,
especially if u have a dictionary of keywords for recursive
leafes.

There is any problem which i don't see with tree-based code?

But i see a serious problems with perfomanse with only some
hundreds bytes of code...


0
Comment actions Permalink

trees are easy.
code trees are not.
dotnet code trees are hell.

sorry kinda nerd poetry.

>> Not everything could be cached.....
>>

"i think you have a major design problem..."
(c) john.
As begun, what do you think about regions in code? You think its
orthogonal to root from any leaf of code-tree.

Look at your File Structure window.

So, when you fail your tree-based reverse-engineering of code - we can
be assured, that you at serious troubles with caching at least.

Excuse, but we do not see that you imagine treelike structure of
parsed code.

Good prepared trees - its a dream for cashing! :)
Its only current leaf and recursive calls in one function
to recursive leafses with a setting a flag "outdate".
And in the second transaction - recalculation of outdated.
Its a Bible.
Shure, not everything could be cached, but in right reverse-engeneered
tree its not depend on file size or class size - its only depends on
recursive nodes vectors count.

Special cases with renaming can be simple fixed at
parsing of error, before you offer a way to fix it by Alt-Enter,
especially if u have a dictionary of keywords for recursive
leafes.
There is any problem which i don't see with tree-based code?

But i see a serious problems with perfomanse with only some hundreds
bytes of code...



0

Please sign in to leave a comment.