I think you can rule out network activity. The simple 4 machine network I
have at home has virtually no activity. As far as consolidating is
concerned, most of these plugins are object based. They build only a few
commands that return objects so there's a lot of functionality built in to
not that many plugins.
I tried some stuff.
With workgroup in place, startup time now about 80 seconds. Time to get prim
cube, about 2.5 seconds. Getting the cube is fast enough, it's the time to
ppg that's slow.
With it taken out, startup time 12 seconds. Time to get prim cube,
instantaneous.
Taking out all the plugins in my workgroup, startup time 76 seconds. Not
really that much difference. Get prim cube, still about 2.5 seconds.
Took out Holger's volume and BA shaders. Start time, 35 seconds. Get prim
cube, much quicker. (sorry, Holger). I think someone mentioned this before?
Took out MuHair. 35 seconds.
Took out few more, not a lot of improvement.
I don't think it's entirely the BA shaders, there's still a ways to go to
get to 12 second load without the workgroup but it does seem there's a class
of addin, of which these are a part, that have a considerable effect on load
times. Maybe it's just the number of shaders in the pack. It may be that my
perception of increased load time has something to do with adding addons to
the workgroup. I'm disinclined to take out too many more right now because
I'm not sure I can get them back again, but it's worth keeping an eye on.
The effect of scripted plugins seems negligible.
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM
> [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Bernard Lebel
> Sent: 31-December-2005 16:06
> To: XSI(at)Softimage.COM
> Subject: Re: slow starting XSI. Again
>
> For the cumulative reasons that you mentioned, few months ago
> at the studio I consolidated the hundred command plugins or
> so into less than 20.
>
> Now there is one plugin per "category", like "rendering",
> "animation", and so on, and one per scripting language.
>
> These plugins have some commands "inline", if I can say
> something like that, where there are commands do the work
> from the plugin, but for the majority of the commands, they
> do nothing more than executing a script file. This way I
> could keep most commands as individual script files, allowing
> plugins to not become gigantic blocs of code.
>
> This seemed to help, but not as much as I would have hoped
> for. I took a measurement before doing that change, but not
> after, as it didn't occur over a short period of time. But
> based on my eye observation and the artists input, it seemed
> to have helped..... a little bit.
>
>
> About the workgroup(s), yeah I have the same feeling. What is
> the weirdest is that these slow downs are happening randomly
> at the studio. For me it was very fast for a long time, then
> started being super slow, then fast, then slow, then it has
> never been that fast since a few weeks. Other users are
> experiencing a similar behavior.
> For some it never got back to full speed, for others it has
> almost never been slow, and for the most part, the change in
> speed was never related to some recognizable event. I have
> told users to clean their user directory every once in a
> while (even wrote them a script for
> that) and also to clear their project list every once in a
> while, but even after that, some still experience this
> slowness, while others have tons of junk all over the place
> and don't have any problem.
>
> So I'm a bit confused about that, to the point where I
> suspect pretty much anything that participate in the workgroup:
> - network activity in general
> - switches synchro
> - permissions on the samba server
> - XSI crash files
> - XSI logs
> - contaminated user directory
> - contaminated workgroup directory
> - Python/pywin32
> - whatever
>
> Our problem with property pages doesn't seem as significant as yours.
> Yes when the launches is slow I have noticed the property
> page thing, but it generally occur only for the first ones
> open, at some point it is responsive.... except for the null
> ppg (somehow they always take 3 seconds to open).
>
>
>
> At home I did a quick test. I have a local workgroup that I
> set through UNC path. That workgroup consist of a handful of
> custom shaders (Binary Alchemy collection, dirtmap and
> simbiontXSI), one custom spdl wih one custom dll, two custom
> toolbars, no custom layout, one relational view that contains
> nothing, and a "plugin loader" that loads about 200 plugin
> files (at home I have not done the consolidation thing)
> located outside the Plugins directory.
>
> I timed the unc workgroup launch, then changed the unc path
> to a drive letter and timed it, then disconnected from the
> workgroup and timed it again.
>
> UNC workgroup: 14:89
> Drive letter workgroup: 13:05
> No workgroup: 7:37
>
> Then, still disconnected from the workgroup, I moved my
> plugin loader into my user Plugins.
>
> Plugin loader in user Plugins: 12:15
>
> Bare in mind, I timed those launches with my watch chrono, so
> it just gives an idea.
>
>
>
> Bernard
>
>
>
> On 12/31/05, kim aldis <kim(at)cg-soup.com> wrote:
> >
> > for me it seems to be tied to the workgroup. I've quite a
> few plugins and stuff there but I've had these in there for
> months now. It's the accumulative thing that concerns me,
> plus, I could live with the slow startup but 2-3 seconds for
> every property page, that's a no-no. Especially for the big ones.
> >
> >
> > ________________________________
> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
> On Behalf Of Bernard Lebel
> > Sent: 31-December-2005 05:07
> > To: XSI(at)Softimage.COM
> > Subject: Re: slow starting XSI. Again
> >
> >
> > I don't know if it has anything to do with your scenario,
> but I observed on many occasions that if I crash during a
> render region, subsequent launches are much, much slower.
> I don't know if it has anything to do with memory, crash
> files/logs being read, or else, but sometimes cleaning my
> user can help, but not always. One day it is fast again
> and I still don't have a clue.
> >
> >
> > Bernard
> >
> >
> >
> >
> > On 12/30/05, kim aldis <kim(at)cg-soup.com> wrote:
> > >
> > > This is getting daft. Seems to be taking longer and
> longer to kick XSI off and it's starting to badly affect the
> bringing up of property pages too. A few weeks ago it was
> taking about a minute to kick off XSI, now it's taking
> two with not really much added to the workgroup. simply
> getting a grid or a sphere takes 2 seconds. Anyone else
> seeing it getting worse?
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
