Editing and typing is slow in VS 2017


(Theo) #21

@ck : I will send it to you too.
I get an Out of memory exception when I compile this project.


(Theo) #22

The code has been send.
edit: But I see that @viktoriad did not receive the mail, @ck, can you send it to viktoriad?


(Carlo Kok) #23

I got it;. I’ll forward it.


(RemObjects) #24

bugs://80903 got closed with status notfixable.


(Carlo Kok) #25

So we’ve spent some time with this project, and improved the compiler a bit, but there’s 150mb of .pas files in a single project. As unicode that becomes 300 mb or so, and when I build my parser tree I vastly exceed the 1.6-1.7 gb .NET lets me allocate in a single process. Not much I can do about that last part though. What I will do is upgrade ebuild & water to run 64bits. This won’t help you inside VS but will in Water and compiling it.

Not sure if we can ever get a project this large to work in VS, if you need it to work there I suggest you split the project up in parts.


(Theo) #26

Can’t you do something with the namespaces?
What I mean, compile per namespace and then merge the obj files?
(I am not hindered by any compiler knowledge, so the above could be rubbish …)


(Carlo Kok) #27

The problem is that ns1 can depend on ns2 and back on ns1 again, so I have to load it and process it all.


(Theo) #28

What is the max compilable size?


(marc hoffman) #29

It’s not really a fixed number that can be put in relation to “lines of code” or the like. Whatever fits in memory, basically.

Tomorrow’s build will build in 54-bit, from command line and in Water.


(Theo) #30

I will use water for this project as it does not rely on any designer.


(marc hoffman) #31

FWIW, typing in the 200k-lines source files seems quite speedy in Fire (didn’t test Water yet, but the same should apply there, as its essentially the same editor) :wink:


(marc hoffman) #32

Also, fwiw, your project goes to 4.6GB (and counting) while i’m building it right now (this is EBuild/Mac, which always ran 64bit). So no surprise it fails on 32bit, where 2GB is the total limit for a process on Windows (3GB if you put Windows in that weird special mode, if that’s still a thing).


(marc hoffman) #33

Update: your project tool 80 minutes to build, and required 8+GB of memory at its peak.

Now, two things here:

(a) the size and scope of this project is excessive, ridiculous and not really supportable, and tis size off project will never be something that works and performs well

(b) there’s probably areas in the compile that could be optimized further where the excessive size of the project does lead to larger slowdowns than it should, and we want to look at that — but this project is too big to even begin using to for any kind of profiling or analysis :(.

Given that the project is largely auto-generated code, I was wondering if by any chance you could generate a similar test case for us that’s, say 50% or 10% the scope of this project — still ridiculously large in scope, but not quite as much so as this one —that we could use for some profiling and review if there’s some unnecessary O(n²) code paths that would not need to be…

thanx,
marc

ps: the same issues that affect the compiler will o curse also affect the IDE. While Fire/Water seem responsive and typing in the individual files is fine, the background code model used for CC & co will and does take a comparable amount of time and memory to build up (and keep up to date) in the background (Fire was at 8GB with the project open, too), so I doubt a project of this size will ever be “workable” in the IDE (ie with working CC, et al).

What I suggest doing would be to split, at least, the auto-generated code into a separate .dll project that would not be part of the main solution you work with, would be built from the command line, and referenced standard .dll reference — for sanity’s sake.


(Theo) #34

Wow! - but it builds. Thanks for that.

Well, it is a United Nations (in other words Goverment) spec. So that is to be expected :smile:

That is not problem - will give it to you next week - I am going to split it in several dll’s, one for each namespace.

That is all that I ask with files this big.

I can understand that.

Will do that :smile:


(Theo) #35

I just split the project into 25 separate projects, one per namespace.
It now takes about 10 minutes to compile from Visual Studio - and it stays within the available memory.
The biggest project is now about 7Mb code.


(marc hoffman) #36

Can we get these as test case to look at for profiling?


(Patrick Lanz) #37

Same thing here.
Suddenly, with a huge project, typing becomes very slow: about 2 seconds for each char I type.
I tried to restart Visual Studio but the same thing appears…
What’s strange is that CC is fast, but typing is slow!

Visual Studio shows the following message:
image

As I can reproduce the problem, I will prepare an upload with the current state of the project and send a private message with a download link.


(marc hoffman) #38

Define “huge”. Theo’s project wasn’t huge, it was ludicrously huge and a size that never can work well.


(Patrick Lanz) #39

I will say about 1M lines of code (.pas, .xml and .xaml) and documentation…


(Theo) #40

:blush: