When opening the same patch, It took about 40 seconds in extended, where vanilla version just took less than 5secs.

I've only used objects working in vanilla so I think there's no difference in loading things.

And about cpu usage, using extended, cpu usage was fluctuating between 5~30%, but vanilla version never exceeded 10%.

I'm using windows XP, core 2duo laptop by the way.

DISCLAIMER: This is entirely speculation on my part, so take this with a grain of salt.

I think cpu usage might have to do with the fact that Pd-extended uses a more up-to-date version of portaudio than vanilla. Hans did once mention that it wasn't his area of expertise, and he wanted some help with it, so it may not be the best implementation. I found a while ago that when using Jack instead of portaudio on OSX that the cpu usage went down dramatically.

Load times might just have something to do with more paths being searched in Pd-x than vanilla.

At any rate, you might get a better answer from the list than here, since the devs hang out there more.

>>Load times might just have something to do with more paths being searched in Pd-x than vanilla.<<

that's pretty much what i think, too.

if they want to fix that, i'd guess the simple solution would be to force every search through the vanilla path first?

>>I think cpu usage might have to do with the fact that Pd-extended uses a more up-to-date version of portaudio than vanilla.<<

Thank you Maelstorm.
Does this mean there can be any difference in audio quality between two?
What's the downside of using vanilla other than unable to use extended objects?

@mod said:

if they want to fix that, i'd guess the simple solution would be to force every search through the vanilla path first?

I would think so. It seems that the a "vanilla" libdir had to be made to ensure that vanilla objects were loaded by default in cases when externals/abstractions shared the same name as vanilla objects. Checking the logs on start-up for Pd-extended, it seems that vanilla is the third libdir loaded, so I wouldn't think it would be significant. I'm guessing the vanilla libdir just isn't complete. I vaguely remember reading a while ago that a loaded library will override vanilla objects, so the vanilla libdir is really a kludge to negate that overriding. But if the vanilla libdir is incomplete, then objects are being searched in every loaded library first before checking if it is an internal. So that could be adding to the load time. Again, I'm speculating quite a bit here.

@cuinjune said:

Does this mean there can be any difference in audio quality between two?
What's the downside of using vanilla other than unable to use extended objects?

I suspect the pros for up-to-date portaudio is better compatibility with drivers, and maybe a boost in quality as far as portaudio itself is concerned. But if the implementation of portaudio isn't as good in Pd-extended as it is in Pd-vanilla, then it doesn't necessarily help. There have been other threads stating that lower latency can be achieved in vanilla, but I haven't really tested it myself. I always use Jack, anyway.

The major upside to Pd-extended is that it comes with a collection of widely used libraries and is itself widely used, meaning that you can write patches using many non-vanilla libraries, yet they will still be easy to share. There are the occasional objects like [import] and [initbang] that simply won't work in vanilla, and some things get implemented in Pd-extended well before they make their way into Pd-vanilla, but beyond that the advantages are generally cosmetic.

Thank you for your answer Maelstorm. You are my Pd Guru!