V17 R5 .toCollection is really slow

Anyone else notice this? It’s crazy that using .toCollection of a fairly large entity selection (all US zip codes) takes 12 seconds, but converting the entity selection to a selection, calling SELECTION TO ARRAY, and then ARRAY TO COLLECTION is less than a second!

Has anyone else reported this and/or tested this on current versions yet? Hoping it’s better in v18.

If you need a flat collection, try entitySelection .extract (“field”) starting with v18R3.

Cool. Yeah a flat collection is best case. Anything more complicated with a decent sized selection of records just completely falls apart.

What is often forgotten,
is the case that a entity selection contains not only the records of one table and all its fields,
it can contains to related infos from other tables.
This one can be slow, if you want to get all thuch datas from server into your collection.
Take a look before into your entity-selection in debugger, too see which data it contains.
If this is only 15.000 Records from one table with 45 Fields and fields contain less data not too-huge-text/Blob/Picture, than this is normally no problem, when you need only 20 Fields of the 45 Fields in collection, this must NOT be .extract() each named field, you can push all fields into collection if you want not to extera list 20 wished Fieldnames. But when you need only 1/2/3 Fields from table, then it is even better to extract entity selection before you tried to push its datas into collection.

Remember always,
entity selection can contains much relatated datas
and can contains huge-field-data what is saved outside the record (e.g. large text).
Never push any entity-selection into a collection without
a look into the entity selection in debugger to see what they are contains
to clearified how much datas must transported.
And calculated the risk what maybe your entity-selection can contains
in any future use-case if related-definitions changed.

without details about your structure I can only guess.
For zip codes, I would expect a small table structure, only 3 fields?
If yes, then I have no idea. Amount of transferred data should be similar.
Maybe possible: a very large table with two fields, like ZIP and city name, needs in two arrays with just the content less bytes compared to a JSON where for each record the field has a label name. As longer your label (field name) and more records, as more bytes needed. More bytes needs more time, especially on slower networks. But that’s a wild guess.

If no, and you use many fields:
SELECTION TO ARRAY creates on the server the arrays for the specified fields and transfers just this arrays.
.toCollection (or .extract) creates on the client a collection, using an already existing client ORDA cache. So if data was already transfered it is way faster, if not, way slower.
Starting with v18 R4 this will be more optimised, to request only missing required information from the server (prebuild on the server), by not touching/changing the learned ORDA context for other operations.