*grumble grumble* hijacking *more angry squidward noises*
It's reasonably related and a likely follow-up question, so I'll leave it here.
The amount of sprites you can have in the resource tree is theoretically unlimited, hardware and data type range limits aside.
Having a truckload of sprites alone will do nothing to performance, as nothing is being done with them at run time.
Having said truckload of sprites
loaded into memory may induce a performance hit upon initially loading the sprites into memory, though, freezing the game until the texture page is loaded (this can take less than a frame for a single texture page or longer depending on how many pages are being loaded and how large they are). Sprites, or, to be specific, the texture pages containing them, are not loaded by default and will only be loaded when attempting to draw a sprite on a texture page that is not yet loaded, or when explicitly loaded via
sprite_prefetch*.
Drawing sprites contributes to the processing workload, and therefore the amount of computing power it takes to process and render a frame. Therefore, drawing more sprites than the target device is capable of handling will eventually lead to slowdown.
Regarding the "heavy animated sprite" part: How a sprite is animated does not matter, as only a single frame of this animation would be drawn at a time. Only said frame will contribute to the processing workload.
The main concerns are how many draw calls you're performing every step and how many of them use sprites that are located on different texture pages. Drawing a sprite that is not located on the texture page that is currently loaded into VRAM will cause a texture swap. (VRAM is not to be confused with RAM - only one texture page can be loaded into VRAM at a time, but many can be loaded into RAM.)
This swap needs to happen because only texture pages loaded into VRAM can be drawn, and the swapping process stalls the draw pipeline as it can not continue until it is completed, therefore inducing another performance hit. Depending on how many texture swaps occur during a frame, the resulting increase in workload may lead to noticeable slowdown. While a low amount of texture swaps is no reason for concern and, depending on the game and its capacity, is a normal occurrence, excessive texture swapping in high double or triple digits should be avoided at all costs, especially on low-performance platforms.
Another concern is RAM usage - I was going back and forth about this with
@kupo15, here and on the old GMC, filter topics by author on both and you're likely to find a gold mine of topics about sprite memory management. The summary is that GMS games are subject to the limitations of 32 bit applications (as of writing), and therefore can only use roughly 2 GB of RAM. This means that it is impossible to keep a theoretically unlimited amount of sprites loaded into memory concurrently, as the amount of available memory is finite.
What's next? "How many sounds can I have in my game"? "How many variables can I have in my game"? "How many times can I hijack this topic before Tsuka blows a fuse"?
Keep 'em coming and we're just a few steps away from turning this into a collective reference about GMS limitations.