So if size doesn't matter that much anymore what does?

Interesting discussion. The long and short is that it is the system and not
any one simple component, the CPU, and chipset, memory bandwidth being the
factors that have to optimized for the hardware to perform well.

I came across a comment by Richard Wagenaar (Nov. 7th, 2004):

Coming from a very old release of Solidworks and now experimenting
with SW2005 I see a huge performance slowdown in several areas.
Even assemblies with 150 unique parts can be extremely slow.
Some commands like edit a sketch of a part while being in an assembly can
be more than 30 times slower causing minuts waiting time which used to be
seconds before. It is bad enough to stop working with SW2005 as the
productivity loss is too big. I am only working with SW2005 on very small
assemblies, big assemblies are for the old release. It is disappointing to
see that performance is going down rapidly with every release. The
lightweight options are only sometimes a solution. If you use in context
relations, base parts, mirrored parts and configurations then lightweight
is causing problems.
Maybe if you can divide the machine in parts that have nothing
to do with each other, then lightweight might be an alternative but with
complex
machine design I cannot see here where it helps as you need to resolve
anyway to rebuild and update correctly after changes.
Richard

And then I came across a comment by Devon Sowell (Sep. 24th, 2004):

Hello Thomas-
There is no simple answer to this problem.
Here is my first question: Are all the assemblies and their components in
"one folder", or are they located in multiple folders? I recommended that
all "released" files, drawings, assemblies, and parts reside in one folder.
In released assemblies, I 'fix" all the components in place and "supress"
all the mates, then the mates "are still there" but are not loaded into
memory. Also, I "delete" all "external references" in "released" parts.
Best Regards,
Devon T. Sowell

 

That is a known slowdown. But you will have to ask Richard that
question. My assumption is that he was experiencing slowdowns not only

What happens if all the old parts are first opened in
the new release and then refiled?
Could be that it's updating *copies* of the old parts
on the fly ...... if they are old.[/QUOTE]

 

[/QUOTE]

There may be lots of "standard" parts/items used in
the "current" stuff.

 

Meaning that they are stored away in some kind of complex directory
structure?

 

No. "Directories" just help find the files in storage. They are
just lookup tables for the area the specific files are stored
in; otherwise the filenames don't exist on disk AFAIK
(except perhaps in the file's headers). On UNIX systems,
as an example, each file has an integer Inode which is te
file .... but the disk/filesystem stores a lookup table with
filenames & inodes to go to to find the file. AFAK the MS
filesystems are very similar .... it's stored in the FAT
(File Access Table) data.
This info contains the full file names, including the full
path from the "root" of the filesystem, such as "C:".
"Moving" a file from one name to another just changes
this data (and perhaps the file's header data).

My comment was that perhaps te application (SW
in this case) must make temp copies of all part files
from prior releases and then update the temp copies
(which you would probably never "see" as a file on disk)
in temp memory or storage to use them in a later release.
It would then delete the temp files when done or the
application (SW) ended, rather than actually updating
the old files on disk (which you may not want in some cases ..
if the data got corrupted or you backed off a release or
the date stamp or SW release level was critical, as examples).

It would have to do this EACH TIME. Perhaps for every instance
of a common item used many places, such as a bolt (depends
on many factors --- including how they did things &
probably your system's resources).

IF the files you need are the current release this may
not need to happen.
IF the part database structure from one release to the next
is constant (unlikely) this may not need to happen.

Anyone is free to correct my assumptions & logic <G>.

HTH

 

Not in answer but I needed a post to post to .... <G>.

If you have a lot of part files created over some time
and use assemblies & suchlike your best bang for the buck
is probably to redo your disk(s) a bit.
Defragmenting the files does not really do the best of
all possible things.

Back everything up. Twice. Verify the backups. As files,
not disk images.
Back up some disk images too, just in case.

Now delete everything on disk, or almost everything. You
can keep the minimal core OS, perhaps.

Defragment what's left.

Now reinstall your *core* applications software. Leave out anything
it does not have to have to run, if you can, like online docs

Now copy your parts back.

In theory, you now have everything on the outside of the disk(s),
where access is faster as well as the files in directories next to
each other (copying files copies them by directory in a linear manner
to the media, be it tape or whatever .... thus getting some neat order
which you can now take advantage of).
In addition, the files are next to the applications software .. less
distance for the head to travel, thus faster access.


Now, as a final step, add back or reinstall everything else.
Should be faster now to use.

HTH

 

Even on striped arrays the heads must still seek from cylinder to
cylinder. All you really get is (we hope) faster data transfer once
the heads are in place to read or write.

Faster options include swap on it's own drive/stripe array,
applications on their own, data files (parts) on their own,
old parts on their own, the OS on it's own. Each with their own
disk controller is even better.

When logical disks (C:, D:, E:, etc.) are on the same physical
drive it can be no faster than one logical drive with all the data
(in general) but can be expected to actually be slower in most
cases as the heads have a greater distance to go between the
cylinders on the various logical drives.
A bit easier to maintain in some cases.

 

Cliff,

I was going in a different direction in my thinking. Read the help on
finding referenced files. There is a thirteen step process (using a lot
of recursion). If SW gets into searching for file and recursing up and
down file trees there can be a lot of overhead. I know about inodes and
how they work and that *nix keeps redundant copies of the inode
structures, etc. Fact is that when SW has to look for/at files in
different directories it has to move the head physically to do so. In a
massively recursive situation this can really slow things down. At
least that is my thought.

 

In such cases you may wish to adjust your PATH statement
so that things are found early on.
On UNIX systems environment variables are nice too <g>.