@solo said:
I do not know the technicality of what is needed or what is going to work better however I do know what I'd like to be able to achieve with Sketchup.
Maybe we can start a new thread and have a real discussion of what can be done to help us with higher poly models, not how to model leaner but rather how SU can be "fixed" to handle more complex scenes.
Many folks believe going 64 bit or multi thread would help, maybe even having a way to turn off the inference engine, I do not know so maybe we can all discuss and perhaps even find a direction y'all may be willing to investigate.
Solo,
This is exactly the kind of thing we've done with our surveys in the past, with only varying levels of success.
What we need to know before we begin investigating performance problems is that people are doing everything they can to follow our previous guidelines about making SketchUp work as well as possible with high-poly models, etc.. Only then can we fairly evaluate the feedback about what kinds of operations are getting people stuck. We need to see consistently and repeatably that under the controlled circumstances we've suggested, the bottlenecks exist <wherever-they-are>. We need to get a really good idea for not just the fact that some operation is a problem, but more importantly, to know the frequencies with which those problems occur. That's what allows us to put together a comprehensive plan to deal with those things that will make the most difference--those items on the critical path, in order of severity, as dictated by overall impact.
In fact, that's exactly what we do with BugSplat. All of the crashes are prioritized by number and frequency of occurrence. When we address them, we do so in that order. That's why you've heard so many people talk about SketchUp crashing less often than ever before.
The problem we've had to this point is that generally, we get a lot of people who cruise the forums and the internet and pick up on buzzwords like "multi-core" and "64-bit" and then instead of following our suggestions for how to use the software and working to give us good feedback on where their limitations are like I've described above, they just come back at us and throw the buzzwords around without doing anything helpful.
For instance, just at this last basecamp, when I asked someone for what I just wrote above, he responded by trying to dictate his own process. He said, "No, it's not my job to do that; I'm paying for Pro and it doesn't work like I want, so that's your job to fix." He said, "Implement 64-bit and multi-core and xyz and then once you're done, you'll see all my problems are solved."
I see that all the time and it does us absolutely no good.
What we need is more people being really cooperative and forthcoming about helping us figure out exactly "what", and fewer people concerned about the "how." Our job is to figure out the "how" after we have a clear idea of "what," not the other way around.
Always asking for "how" is just a recipe for disaster: Either we give you nothing but the "how" because that's what you insisted we do, though it doesn't actually do anything to satisfy, or we do our damnedest to figure out the "what" on our own and implement an appropriate "how", only to find that the "what" we did isn't the as important as the "what" we didn't.
And believe me when I say that at least half of the time people think they're giving us a "what", they're actually giving a "how"; not necessarily to be obstinate, but because they don't actually realize their proposed improvement actually dictates a particular implementation.
I think the issue for the immediate moment though is that we've done a reasonable job of collecting quite a bit of "what" and are in various stages of working through that stuff. The progress just never seems fast enough to satisfy. Plus all the while, we continue to have to try to quell the storms of people demanding their own "how".
One of the ideas we've kicked around in the past is trying to create a sort of monitoring utility inside of SketchUp that we could use under some circumstances to try to collect really good data of the sort we need to figure out exactly where the problems are coming from. The problem is that it's a bit too much like Schrodinger's box, where the impact of running tools to observe the problems actually masks what's really happening by changing the timing and overall speed. Whatever the case may be, please trust me when I say we're always interested in trying to improve performance, although we simply can't sacrifice everything else to get it.
Andrew
Getting high would make work a lot more interesting, but were that part of our regular development practice, I'm not sure we'd have ever gotten around to fixing the shadow bug, let alone going to 64-bit.
