Exponential sets can be computationally expensive to humanize

[GreenReaper]

The set [Y3378E4..Y3389E4] results in a gzipped API response of 223.90 KB (1.05 MB decompressed) and takes seconds to generate (on WBStack). Starting the range with Y3278E4 resulted in an internal server error after five seconds. (The 'Y's are optional.)

I'm guessing a large part of the issue is how it humanizes the resulting set, which seems liable to exhaust memory:

(One of these: 33780000, 33780001, 33780002, 33780003, 33780004, 33780005, {... ~9995 more years}, 33890000)

rather than something like:

(One of these: 33780000 through 33890000)

More generally it may be worth limiting the length of the output; ProfessionalWiki/WikibaseEdtf#11 seems to touch on this but perhaps didn't consider this case. Beyond a certain point the humanization becomes non-useful, and if anything it might be best to skip to the last item. Or maybe each range in the set could only contribute a certain number of entries to the humanization, including its first and last items?

(One of these: 1990, 1991, 1992, 1993, [...], 2000, 33780000, 33780001, 33780002, 33780003, [...], 33890000) {with [...] as shown}

[JeroenDeDauw]

Thanks for reporting this issue!

I'm afraid this might go deeper than just the humanization but I need to double check.

[JeroenDeDauw]

Partially a duplicate of #58