Herb's last appearance on C9 was a relatively short chat about C++0x. You wanted more questions so Herb decided that the best way to get the questions you want asked is, well, to have you ask them. Most of the highest user-rated questions were asked and Herb answers with his usual precision. So, without further ado, it's C++ question and answer time with the great Herb Sutter, powered by you.
[Watch the entire interview in Channel 9]
My configuration is on par with yours. I have 12 GB RAM, but other components are the same: Core i7, SSD, plus I have a very fast RAID array.
This. Does. Not. Help.
Sure, on small projects, like examples, or things like, say, ZLib, the performance is OK. Not great, mind you, the performance gradually becomes worse the more you work with the project, so it is *still* possible to get VS2010 into a state where it visible lags as you type and a simple F3 (find next sequence of characters) takes seconds. Not great, but OK.
However, if we take one of the real projects which we actually use for work (nothing too unusual, 2-3 million lines of code, tightly organized), VS2010 becomes very slow very fast. And the kick is, VS2008 doesn't.
So, no, perhaps upgrading might help someone, but it is not the end of the story by far.
I'm not sure in which place I've made a statement about you that is not true. I can only guess that the place you're referring to is "you've missed the point". Well, from your post it looked like you did. Mind you, in your post you've never and nowhere indicated that your post has humorous/cynical undertone.
Anyway, I didn't mean to hurt/insult you, I just wanted to clarify few things and one of them is that VS2010 performes horribly compared to VS2008.
@PleaseFixYourBugs Good to see a counter example. I haven't worked with a solution with that many lines of code in it (used to use SourceInsight for the large C++ code bases I worked with from '02-'07), so that has me wondering how beefy of a machine would be required to get acceptable perf on a solution that large with VS2010.
Try excluding Boost and your other source code directories from AV scans. SQL data and VM are also good candidates for exclusion.
I don't know why my comment vanished. I know that nobody asked Herb about C++/CLI. But I'd like C++/CLI to get some more love from MSFT. It is absolutely essential for our apps: number crunching is done in C++ (C-like C++), while SQL and XML support is done via .NET. For us C++/CLI offers the only practical way to put data from C++ structs to SQL and XML.
Josh, we have been working with projects of that size for a long time. With some minimal structure and simple rules (mainly for the include hierarchy / pimpls), it is completely possible to work with projects of several million lines in any IDE. The hardware today is plenty fast. Building our main project from scratch on the machine I described (very similar to yours) takes 15-20 minutes per configuration. Scanning the entire codebase for dependencies takes seconds. It has been that way for years. VS2005 and VS2008 both handle the project without breaking a sweat. VS2010 doesn't. When an upgrade to a new version of the product is really a downgrade, something is seriously wrong.
To JSawyer: We don't use Boost. We aren't template-heavy at all. No SQL data. I am not sure what you mean by VM, if that's Virtual Machines, we don't use them.
Oh, yes, no AV scans at all on the development machines.
I just meant that people should exclude SDKs and other source code heavy directories (such as Boost) from AV scans. If you run SQL and VM, then you should exclude their directories too.
But if you don't have real time protection, it's still advisable to run a scheduled scan over night.
@Herb Sutter && / || @Tony Goodhew
I did ask this question a week ago and still didn't get any answer, so could you please:
Answer (here or anywhere really) how much of C++11 will be implemented in VS.next?
I haven't got answers to my questions either (post 4, I am asking if Charles would consider doing an interview with specific people).
I am beginning to wonder about the purpose of this blog. So far It seems to exist mostly so that the team can point some higher-up to its URL saying "see, we are talking to our customers, we care about our product, please give us a raise".
@PleaseFixYourBugs just like I've said: Manager is doing what he was told to do, making good face to bad game.
Do not have hope for VS.next. I'm telling you that, and you will remember my words. (If not I will remind you about them, I've got them copied and stored for later use after VS.next will get released ;)
@Diegum any reason you do not participate in this discussion?
@Microsoft will anyone respond and answer to those questions?
@PleaseFixYourBugs - Just wanted to thank you for taking the time to hijack numerous recent VC++ team blog entries in order to express your discontent with VS2010 performance, etc.
Really - we all love coming to this blog and weeding through your many, many complaints. It's exactly what we come here for. Your problems should be *everyone's* problems.
And, after all, your choice of tactics are proving to be so *very* effective.
Keep up the great work.
@MR Correct me if I'm wrong but I feel that your comment is bit a sarcastic attack on PleaseFixYourBugs. If so I have to protest.
The reason for it is that his complaints are valid (you can go through any of them and check if they appear on your machine), and yes, if he complains about software which have notorious bugs and *YOU* use this software on regular basis then YES THAT SHOULD ALSO BE YOUR PROBLEM.
And as for reason for coming here? Well, that surely differ but I see this particular forum as a way of discussing things with VS Team and it seems to me that PleaseFixYourBugs have similar approach. Is there something inappropriate in this behaviour? If so what? Would you mind to specify?
And please note, that just because someone is complaining it does not mean that this person is a "trouble maker". I personally also complain a lot. Why? Because I hope that by saying aloud what I think about how things are done in this world maybe, just maybe will help to improve some of them.
And now question to you:
If software is buggy/low performing etc. etc. do you think that it is appropriate to complain about it or not?
@MR - I, for one, am grateful that PleaseFixYourBugs raises these problems. They are real problems. I am experiencing some (most) of them as well on a daily basis.
I doubt the lack of visible effect from these threads is due to a wrong choice of tactics on PleaseFixYourBugs' part. What do you suggest he does? He did file reports on Connect, like many of us. This has no effect. What else? Shut up and live with the bugs? Fine, he will shut up, but someone else will start saying the same things. What would that change? You see, the only solution is to fix the damn product. If you have any ideas as to how we could convince the VS team to do that besides posting on blogs and forums, please share them.
I would suggest that if the VS team actually talked to PleaseFixYourBugs and others in threads on this blog, the amount of expressed discontent would be much lower. Replies like the one from Tony Goodhew that mostly restate that things are difficult don't count. No offense to Tony, but they just don't.
@PleaseFixYourBugs - Thank you. I share your frustration with the quality of VS 2010. Let's hope one day someone from Microsoft will finally hear us and give VS 2010 the kick it deserves.
I added my experience to a VS2010 perf related report on Connect that I recall was closed as not reproduceable inspite of multipel people reporting the same issue. I for one do not plan to waste my time there again.
Additinionally, the question I asked further up this comment thread has also not be answered, although on one of the recent channel 9 comment threads an MSFT employee linked to this blog as a place to engage the VC team. I would point out that it takes two way communication to have engagement. If its one way, then it will be presumed to be just another blackhole into which communications die.
I've been monitoring this thread, but curiously, nobody has issues with our C++ Standard Library implementation (which I maintain). :->
We haven't yet announced which C++0x features have been implemented in VC11.