It depends on the method and complexity of synthesis - if you use filters, feedback and anti-aliasing filters ect.
The sampler might basicly be arrays as look-up tables < read interpolated with tabread4~ with a phasor~ < modulated with ramps and some AM.
With similar ingredients you can already patch a very basic synth but more complexity will require some more cpu.
If you want time-stretching and independent pitch-modulation, the sampler will become more complex with FFT.
(You see, in reality either one becomes a hybrid quickly: for example [cos~] is a table-lookup, too.)
Reading a complex pre-made sample will use the same CPU as a very basic sound.
A sampler will require more RAM, as the arrays are stored in memory. You can easily calculate the reqired space for this if you know samplelength, bits and samplerate.
Given the synth- or sampler-apps available for phones, I guess you can patch quite complex instruments in either way. Of course this depends on other expensive tasks running along with it.
The CPU-load depends on blocksize and latency, too.
Often in PD-Vanilla the bottleneck are the GUI elements, wich you might not use anyway.

@jameslo The bug is the delaylines~ not having 1 sample delay.
I am not entirely sure why, but you read them at 0ms, - arguments are in ms not samples and there is the importance of the execution order with delays~, and s~ r~, you can read about in audio.examples/G05.execution.order.pd
But this would lead to a DSP-loop here.

However, I use tabsend~ tabreceive~ and 1 sample arrays, as this is how to do feedback-loops with 1 sample delay.
I created the sending subpatches first, the receiving ones afterwards, - not sure if this is important for the execution order in this case, too?
biquad-resonator-debug_2c.pd

@pharaoh-sean
help > find externals
And please read how to deal with externals in the manual: help > manual > chapter 4 externals
To be sure, delete the zexy folder in /extra before reinstalling it with Deken

(Also, I'd recommend to download the latest version of PD Vanilla from here https://puredata.info/downloads
or there http://msp.ucsd.edu/software.html
instead of using possibly outdated repositories (i.e. Synaptics). But this is unrelated to your question. )

@RetroMaximus mapping might help
map.pd
map-help.pd

@pharaoh-sean After installing Zexy via Deken,

try adding zexy to File > Preferences > Libraries

or add
[declare -lib zexy]
beforehand
[demux]
in your patch.

In File > Preferences > Searchpaths should be PD's /extra folder, and the library should be inside of that folder, of course.

similiar thread here:
https://forum.pdpatchrepo.info/topic/12786/iemlib-in-vanilla-deken-compiling/11

@adammccaffrey you can find the error message in the sources:
https://github.com/pure-data/pure-data/blob/master/src/m_memory.c

the patch is resizing the cloned arrays
here it uses >4Gb of ram

operating system? 32 / 64 bit?
PD-version? 32 /64 bit?

@adammccaffrey probably running out of memory.
How much Random Access Memory does your machine have?

@cfry No, the quote posted by @ddw_music is related to PD's scheduler and the basic difference between update-rates of control versus signal~objects.
You can read about it in PD's manual chapter "scheduling" in the help-menu.

[noise~] has to calculate 44100 random numbers per second, whether you do anything with those numbers or not. [random] just runs when you ask it to.

... and you can poll it every 64 samples only.
That is why

There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block.

and why [noise~] with the output of [snapshot~] has no advantage over [random].

When I did a comparison test with just one of each (set to fast rate), the cpu load did not differ much

You will only feel the difference in huge patches with many [clone]s and or upsampling in the sum with many other things running.

I am modifying an polyphonic FM synth, which has cloned objects with [phasor~] inside.

Is the random generated inside of the [clone]?
If not, something else might cause high CPU-load.

The cheapest way to get random might not be calculating it in realtime, but reading preset random numbers from a text- or wavefile or an array with phasor~ or [f][+ 1]. But then the random set will loop.

@whale-av @jameslo
now [declare -lib iemlib] made it with 1.22 from Deken on Win10
sorry for the false alarm! and thank you *

@whale-av does t3_delay-help.pd work on your machine?