PDA

View Full Version : Frustrated w/performance



sjsl
2005-09-06, 07:55 PM
Just upgraded our computers to 2.8/2g per machine (dual core machines). We have envoked worksets, design options, etc.

Our project is a large one 500k in size on two floors, just moving an interior partition a couple of feet takes 30 secs, moving a door 20 secs, I could go on and on. Has anyone else hit a plateau w/Revit on large projects? Our two users are pulling their hair out. We are considering moving this project back to plain Acad to meet our deadline.

Our reseller was here a week ago and said the software is about 5 yrs ahead of the hardware. Great.

Any comments are welcome and appreciated.

aaronrumple
2005-09-06, 08:13 PM
Finished a 60 Mb project with no problems. 500K is nothing.

Novell or other non-Windows network?

sjsl
2005-09-06, 08:17 PM
No, network issues are not the problem. I too have a hotel project that has performance issues when I try to delete things. It takes forever.

Does a network license have any performance hits from a standalone?

Wes Macaulay
2005-09-06, 08:24 PM
Network licensing should not be an issue. Get a support request going and upload the file!

aaronrumple
2005-09-06, 08:25 PM
We had a huge slow down with 8.0 - very similar to what you describe. It was traced to Novell by Autodesk. Moving our file to a Windows server solved the performance problem. We use network licenses and have never had a problem with that aspect of Revit.

GuyR
2005-09-06, 08:29 PM
Just upgraded our computers to 2.8/2g per machine (dual core machines). We have envoked worksets, design options, etc.

Revit will only use 1 core. And if the dualcores are Intel dualcores then each core only runs at 1/2 speed or in your case 1.4Ghz. Still wouldn't have expected it to be that slow.

Single core Intels, dualcore AMD's are the best cost/performance options for Revit at the moment.

Could it be graphics cards? Do you have shadows turned on?

Guy

iru69
2005-09-06, 09:16 PM
And if the dualcores are Intel dualcores then each core only runs at 1/2 speed or in your case 1.4Ghz. Still wouldn't have expected it to be that slow.
Not quite right. The dual-cores he would be referring to are the P D 820 - each core runs at 2.8GHz. (unless they're xeon processors which would be two separate cpu's at 2.8GHz)

Unfortunately, by today's standards, 2.8GHz is not a very fast cpu for an intensive cpu app like Revit. As Guy indicates, Revit (aside from rendering) doesn't take advantage of dual cores - which means sjsl is essentially running Revit on 2.8GHz cpu. The money would have been more wisely spent on a faster single-core P4 at 3.8GHz (or similar Athlon cpu). Though the cpu may not be entirely responsible for the lackluster performance that sjsl describes, it certainly doesn't help.

iru69
2005-09-06, 09:28 PM
BTW, I assume the 500K refers to square footage - not file size (I have family files that are bigger than 500KB). What's the size of the project file?

BWG
2005-09-06, 09:34 PM
If you have a floor and roof and a lot of other interdependent elements in the file and attached to the walls, it can take Revit a while to adjust everything and make sure your actions are not causing an interference somewhere - e.g. the roof not able to be created, etc.

GuyR
2005-09-06, 09:49 PM
I don't seem to be doing well with my hardware explanations at the moment:-)

From here (http://www.tomshardware.com/cpu/20050509/index.html)


The first surprise here is that unlike Intel, thermal issues did not force AMD to reduce average clock speeds to operate two processor cores on one physical chip. This means that AMD dual core processors should run exactly as fast as their single core versions running at the same clock speed

I guess what I'm saying is AMD dualcores really are dual cores. While Intels aren't currently. And unless you get the extreme editions of the 840's then you don't get hyperthreading either.

Guy

fernando
2005-09-06, 09:50 PM
some time ago i get the same problem in project's not started by me, but from other user
i open is project and when i try a simple move of an interior wall i get minutes to wait

it is strange, because i was using the same machine, and Revit version where i do all my kind of work. some of than really complex im shape and volume of constrution

after a small analise i think that all came from the way that user , use to attach wall to floor
to much time, rather than constrain the wall to levels ant to top and base offset. i redraw all the model and had no problems

i think that all that kind of problem came form an abuse of attachment more than using constrains

also some family with dwg inside some times give me troubles


my half Euro , on this tread

BWG
2005-09-06, 10:03 PM
I don't seem to be doing well with my hardware explanations at the moment:-)

From here (http://www.tomshardware.com/cpu/20050509/index.html)



I guess what I'm saying is AMD dualcores really are dual cores. While Intels aren't currently. And unless you get the extreme editions of the 840's then you don't get hyperthreading either.

Guy

If you have dual cores, but only one socket, wouldn't that really be just 1/2 speed for either. Esp. since dual cores and single cores are interchangeable. Only one pipeline coming to the socket. Chipsets can handle the dual core issue, but still, are they putting in more pipeline, but not using them for the single cores? Kinda like memory slots or pci slots?

iru69
2005-09-06, 10:04 PM
I guess what I'm saying is AMD dualcores really are dual cores. While Intels aren't currently. And unless you get the extreme editions of the 840's then you don't get hyperthreading either.
Sorry Guy... the 8xx *are* true dual core - as dual core as the Athlon dual cores (though there are subtle differences about how they work). And the lack of hyperthreading isn't really as big a deal with dual core cpus since hyperthreading is simply a way of getting some of the benefits of dual cores without actually having them (kind of like a virtual dual cores). No worries - we're all still learning about this stuff.

LRaiz
2005-09-06, 10:20 PM
It is not very likely that described performance problems are related to hardware. It is more likely that problems have something to do with a particular way how this project is made. There could be a few rotten elements that cause the general slowdown. Since Revit is always trying to propagate changes from one element to another a few bad elements may actually cause too much superfluous change propagation. I suggest to first try the new 8.1 audit command and see if it can cure the problem. If it does not then contact customer support and ask them to investigate. Even 500K sq.feet project should exhibit better performance.

Tom Dorner
2005-09-06, 10:25 PM
Watch the status bar when things are taking a long time to update, It can give you valuable clues to what is causing the slowdown. We had a similar problem in a 300,000 SF project and somehow one of the groups in the project was being updated by changes that were not group related. I noticed this group reference being updated via the status line, remade the group and all was well again.

HTH

Tom

sjsl
2005-09-07, 12:11 AM
Thanks for all of the replies. Very insightful. I did not know about the audit feature and will give this a try.

BTW the file file size is pushing 50megs plus.

kpaxton
2005-09-07, 01:39 AM
Thanks for all of the replies. Very insightful. I did not know about the audit feature and will give this a try.

BTW the file file size is pushing 50megs plus.
sjsl,

For the most part, I would have to second the suggestions that the others have made. There is usually not one, but two or more culprits at hand when problems like these crop up. I'm not sure it's going to be your hardware unless you've got some bad configs (such as the wrong speed memory with your CPU), and could be tied to the type of network you have (novell, etc.) but more often has to do with some settings in the program itself. I tend to work on two machines - an AMD AthlonXP 3000+ (2.1 gHz) and an AMD Athlon64 4000+ (2.4 gHz). Although the 3000 is half the pipeline of the other, it still holds its head high when doing the initial project layouts, etc. I can see a difference in performance when the file sizes get above 35 mb, and rendertimes are slightly longer.

The one thing I have noticed on any machine I've worked on that directly affects the performance and displays the same amount of lag you're referring to is what tomdinmn mentioned - Groups. I'm currently working on a file that is a project which is 11 stories tall. There are multiple floors that are repeated, so I thought groups were the answer. Once I had them made, then tried to start make edits, adds, removals, etc... the lag hit hard and heavy. Everytime I made a modification, the cpu would have to recalc everything in that goup, then add it to all the others. It would cause slowdowns even when editing items not in a group. I eventually had to blow the groups away - and I noticed an immediate improvement in speed. And this is a model that is nearly 50 mb in size and is very sweep-use intensive!!

At this point it's hard for me, or for the others, to comment more and give you additional advice, because there just isn't enough information on your project to know what might be causing the slowdowns. In the meantime... double check the following:


Limited amount of groups / Check their definitions
No views that have shadows on (Advanced Model Graphics) while editing.
Turn 'overlay planes' off - under Options / Graphics.
Verify you don't have Imports/Links of DWGs that have Xrefs attached to them.
Good luck!
-Kyle

Tom Dorner
2005-09-07, 01:51 AM
Kyle is correct about the group thing. I though it was just our project, but it sounds like he had the same problem we experienced. We ended up with a group that started to interact with every change made to the model even though those elements were not included in the group definition. For example, to change a grid number 300 feet away from the group (did not intersect the group) required a recalculation of the group definition. Once we blew the problem group away the problem stopped. There are still many other groups in the project that behave properly. We started this particular project in 8.0 took it to 8.1, ran the audit and still had the problem until the problem group was eliminated.

That's my story....hope it helps someone out.

Tom

rod.74246
2005-09-07, 09:41 AM
Aye if you are using groups this will cause a lot of problems. In fact Groups are my one big problem with Revit. I've actually instigated a ban on them in our office for a number of reasons. Performance is the first one, secondly is that annoying setup where revit will automatically select a group that you might be hovering over first prior to everything else.

Could be a good idea to have a good look at these from a dev perspective at some point,

hand471037
2005-09-07, 03:10 PM
Aye if you are using groups this will cause a lot of problems. In fact Groups are my one big problem with Revit. I've actually instigated a ban on them in our office for a number of reasons. Performance is the first one, secondly is that annoying setup where revit will automatically select a group that you might be hovering over first prior to everything else.

It's not the best approach, but now that you can schedule across linked projects you might want to replace some of your Groups with Linked in Revit files. This adds some complexity when tagging/annotating/detailing, unfortunately, but it can make things somewhat better, esp. with repetitive layouts (such as unit plan interiors).

neb1998
2005-09-08, 03:40 AM
It is not very likely that described performance problems are related to hardware. It is more likely that problems have something to do with a particular way how this project is made. There could be a few rotten elements that cause the general slowdown. Since Revit is always trying to propagate changes from one element to another a few bad elements may actually cause too much superfluous change propagation. I suggest to first try the new 8.1 audit command and see if it can cure the problem. If it does not then contact customer support and ask them to investigate. Even 500K sq.feet project should exhibit better performance.
This issue with the possiblity of "rotten elements" i have somewhat traced to elements that are created in the beginning of a large project. Like an exterior wall that you draw based on setback requirements and then later try to change. Moving these walls can take a long time even with a very fast machine -- I had the problem on an old 2.8ghz dual xeon p4 pc with 2 gig ram and had the same problem with my new workstation thats a athlon fx-55 with 4 gig of ram. It appears to be a bug or glitch or whatever you want to call it in the project file itself.

Large projects seem to always slow down a bit, but this problem is one that really seems like an unnecessary slowdown (when it happens) -- I have only had the issue a few days but its killer.

my 2 cents

Shaun v Rooyen
2005-09-08, 08:36 AM
.....something to do with a particular way how this project is made. There could be a few rotten elements that cause the general slowdown. .........

Totally agree With Leonid. A while back Wes started "Monster Projects" thread
and my findings are stated there. What causes "Bloat" to Projects
http://forums.augi.com/showthread.php?t=18783&highlight=monster+projects


Wes. Our smallest project is just short of 90MB. All documentation is done in Revit, not one ounce in acad. We build a stack of families!

There are two significant things we have noticed with big files:
1.Don't model anything in the project (in place families).Rather build the family.
2. Stay away from lines, both model + detail. rather build the family.
3. Reduce the dwg usage. ie We will bring a dwg in to model the topography. Once done the dwg is deleted. Same applies to existing buildings.We have no dwg's in our projects, what so ever!!!!!!

We have found that by eliminating the fore mentioned we have in some cases cleaned and reduced our file sizes up to 25%.............. Families ARE your Friends!.

Amoung other tips at and Ideas http://forums.augi.com/showthread.php?p=134694#post134694

To simplifiy "Rotten elements". There is a user here who has a small yet massive statement in his signiture "Model it as you would build it.....". You cannot believe how true to form this is. If you apply his simplicity, "Bloated files", become a thing of the past.

hand471037
2005-09-08, 02:36 PM
To simplifiy "Rotten elements". There is a user here who has a small yet massive statement in his signiture "Model it as you would build it.....". You cannot believe how true to form this is. If you apply his simplicity, "Bloated files", become a thing of the past.

Yes, it takes a touch of discipline, but in the end it works out to be the most efficient and it can really save your hide when design/documentation problems crop up. However it does take someone good at building Families, but at least that 'customization' of Family creation can be reused forever. I've got Families I built in 3.1 that I still use sometimes...

And just a quick note: Raster Images add *a lot* to the file size, and are also to be avoided if possible.

Oh, and one last thing I just remembered: sometimes limiting the number of hosted elements can improve performance when you've got a whole lot of them within the model. For example, when I worked at a place that did multi-unit housing, we'd make the toilets and the cabinets *not* be wall-hosted elements, because having 300 toilets (or more) that all are stuck to a wall is 300 more things Revit has to think about when those walls are touched for some reason. And those toilets were part of the Unit's Group anyways, so if the wall moved from some reason you would simply move the toilet manually within the group and have it update everywhere- and it's not like that happened more than once or twice over the course of the project. So by minimizing the relationships and constraints to only where they were needed and by keeping it simple we noticed a performance benefit...

cblackford
2005-11-14, 04:25 PM
We had a huge slow down with 8.0 - very similar to what you describe. It was traced to Novell by Autodesk. Moving our file to a Windows server solved the performance problem. We use network licenses and have never had a problem with that aspect of Revit.Posted THIS TIP (http://forums.augi.com/showthread.php?p=220597) in another thread this morning

[Mod edit: removed cross post, add link instead]

sbrown
2005-11-14, 07:40 PM
I agree its most likely not hardware but model elements relating to eachother. I've seen linework cause it, I've seen groups, wallsweeps, etc. I think its worth sending to revit for their analysis and report. Sometimes its worth deleteing portions and rebuilding.

lev.lipkin
2005-11-15, 03:54 PM
Please make sure you tried latest 8.1 build. A few performance fixes went into latest build based on feedback on 'invitation only' 8.1 builds.

Jit
2005-11-16, 04:34 AM
Long shot but

hope your machine is running not too hot

hand471037
2005-11-16, 05:11 PM
Long shot but

hope your machine is running not too hot

Not so much of a long shot. I used to have a dual-AMD box that on hot days would choke, but only when running Linux (???), and it took a long time to track it down to one of the fans not working properly...