Featurescript: building arrays

I need to build an array of values and nested arrays in featurescript. They won't be long arrays, typically 100 items for all items but I'm concerned about the "append" command which says "Returns a copy of an array with a single value added to the end." Is there a better way?I could use a 'map' with an index but it is a lot of extra complexity.

0

Comments

Arrays in FS are "functional", so internally, append does not usually copy the array, but rather reuses the data in the argument. A sequence of appends is actually significantly more efficient than a sequence of index-based modifications. The latest version of std has a number of optimizations to containers.fs, so make sure you're using this (e.g., concatenateArrays call used to be very slow, but now it's fast, as it's done in C++). Also, the FS profiler is your friend and guide here.

Excellent reply and exactly what I hoped you would say! I take it by latest version you mean the import(path : "onshape/std/geometry.fs", version : "660.0"); How do I find out what the latest version is, I've looked around the website but can't see a list of updates (changelog) for the std files?

Will look into the profiler more, didn't think of checking that for myself.

For posterity, and since we are lacking solid documentation on this, I'll add a bit more detail:

If implemented in a language like C, your concerns about append() would absolutely be legitimate. However, in FeatureScript, the language is internally implemented to optimize out the performance and memory concerns of this case and many others like it.

In our documentation, you can read that all FeatureScript values have value semantics (except for a box, which behaves like a pointer in C). This means that, following a statement like newArray = append(oldArray, "newThing"); , a change to newArray will not change oldArray.

What's not in the docs yet is that these value semantics are internally implemented as copy-on-write. This means that, if you don't change either array, the two will secretly share the same location in memory. This memory sharing is completely opaque to the author. The language itself will take care doing the copying when necessary, so to a FeatureScript author, it appears that a copy was made all along.

In the case of arrays and maps, that copy-on-write behavior also applies recursively to values within the array (so that, after one element is changed int a large array, most of the memory will still be shared).

Within this implementation, building an array with append() is a critical specific case we've optimized for. This means append() is in practice the fastest way to populate an array in FeatureScript (faster, even, than using makeArray() and setting all its elements).

There are a couple different ways you can find the correct number. The easiest is probably making a new document, and making a Feature Studio in that document, and checking what number is at the top of that Feature Studio.

The more exact way of doing this is actually looking at the standard library version. Here is the Onshape standard library:https://cad.onshape.com/documents/12312312345abcabcabcdeffIt can be found by searching 'std' on public documents, and looking for the one that is owned by Onshape (but we are looking to make it easier to find in the future).

The current version is accessible by looking at its version graph (or any of the imports in any of the files of the library):

Ah, I see. Strangely I didn't for one minute think it actually passed the array by value, i.e. made a deep copy of it, so yes I should have expected that it would be optimised to just append a value (presumably internally as a linked list).