I'm trying to create an immutable list of immutable items.
I've seen and tried BuiltList from built_collection, now I've seen List.unmodifiable.
Are they equivalent i.e. using them I come up to the same result, which is having an unmodifiable list of items?
As far as I can tell, BuiltList returns an Iterable, while List.unmodifiable returns a list.
BuiltList supports the builder pattern used everywhere in built_value which makes it easy to create modified copies and be used together with generated built_value classes.
If you don't need this, just stick with List.unmodifiable
Related
A quick screenshot with the point of interest:
There are 2 questions here.
This happens in a tight loop. The 12.8% code is this:
{
this with Side = side; PositionPrice = position'; StopLossPrice = sl'; TakeProfitPrice = tp'; Volume = this.Volume + this.Quantity * position'
}
This object is passed around a lot and has 23 fields so it's not tiny. It looks like immutability is great for stable code, but it's horrible for performance.
Since this recursive loop is run in parallel, I need to store it's context variables in an object.
I am looking for a general idea of what makes sense, not something specific to that code because I have a few tight loops with a bunch of math which I need to profile as well. I am sure I'll find the same pattern in several places.
The flaw here is that I store both the context for the calculations and its variables in a singe type that gets passed in the loop. As the variable fields get updated, the whole object has to be recreated.
What would make sense here (in general for this type of situations)?
make the fields that can change mutable. In this case, that means keeping the type as is (23 fields) and make some fields mutable (only 5 fields get regularly changed)
move the mutable fields to their own type to have a general context object and one holding all the variables. In this case, that means having a context with (23 - 5 fields) and a separate 5 fields type
make the mutable fields variables and move them out of the type. In this case, these 5 fields would be passed as variables in the recursive loop?
and for the second question:
I have no idea what the 10.0% line with get_Tag is. I have nothing called 'Tag' in the code, so I assume that's a dotnet internal thing.
I have a type called Side and there is a field with the same name used in the loop, but what is the 'Tag' part?
What I would suggest is not to modify your existing immutable type at all. Instead, create a new type with mutable fields that is only used within your tight loop. If the type leaves that loop, convert it back to your immutable type (assuming you don't need a copy to go through the rest of your program with every iteration).
get_Tag in this case is likely the auto-generated get-only property on a discriminated union, it's just how the F# compiler represents this sort of type in CLR. The property can most easily be seen when looking at F# code from C#, here's a great page on F# decompiled:
https://fsharpforfunandprofit.com/posts/fsharp-decompiled/#unions
For the performance issues I can only offer some suggestions:
If you can constrain the context object to your code only, then try making a mutable version and see which effect it has.
You mention that the context object is quite large, is it possible to split it up?
Most of what I know is Javascript. I believe "Lists" are the closest thing Dart has to Arrays, but are they technically the same thing? Is it wrong to think of them as Arrays? Similarly, would Maps be considered Objects? I realize there are likely differences, but would it be "wrong" to make that comparison?
JavaScript Array objects are similar to Dart growable List objects. Both can be added to and accessed by index. Dart lists can only be accessed by index, where JavaScript lists are full JavaScript objects (see below), it just has a magic length property that is only updated when using integer-named properties. In practice, use a Dart List where you would have used a JavaScript Array.
JavaScript Objects are a combination of multiple things. They are mappings from string names to values - that part is best simulated by a Dart Map<String, Object>. They also allow prototype based inheritance, and if you are using that, you probably want to define a Dart class instead. As a data structure, use a Dart Map where you would have used a JavaScript {} object.
Everything is an object in Dart.
EVERYTHING
Everything in Dart is an Object - a List, a Map, even an int:
https://www.dartlang.org/guides/language/language-tour#important-concepts
Dart has Lists which are ordered sequences of objects. There is no class or interface called Array, though Lists act extremely similar to Arrays you might have encountered in other programming languages.
Everything in Dart is an Object.
List is pretty close to JS Array.
Map is somewhat related to Object in JS, but not quite.
A map is just to store keys and values together, but in Dart you can have non-string keys. There are also no prototypes or similar for maps in Dart.
So I am trying to use the F# Set as a hash table. But my element type doesn't implement the IComparable interface (although it implements IEquatable). I got an error saying the construction is not allowed because of comparison constraint. And through some further read, I discovered that F# Set is implemented using binary tree, which makes insertion causes O(log(n)). This looks weird to me, why is the Set structure designed this way?
Edit: So I learned that Set in F# is actually a SortedSet. And I guess the question becomes, why is Sorted Set somehow more preferable than a general Hash Set as an immutable/functional data structure?
There are two important points that should help you understand how sets in F# (and in functional languages in general) work and how they are used:
Implementing immutable hashtables (like .NET HashSet) is hard - when you remove or add elements, you want to avoid copying everything in the data structure and (as far as I know) there is no general way of doing that (you would end up copying too much, so it would be inefficient).
For this reason, most functional sets are implemented as (some form of trees). Those require comparison to build a sorted tree. The nice property of balanced trees is that removing and adding elements does not have to copy everything in the tree, so even the worst case scenario is reasonably efficient (though mutable hashtable is still faster).
Now, F# is functional-first, which means that immutable structures are preferred, but it is perfectly fine to use mutable data structures (especially if you limit the usage to some well defined and restricted scope). For this reason, F# programmers often use Dictionary or HashSet, especially when this is only within the scope of a single function.
I have implemented IEnumerable for a collection I built, and (although I have not tested them all) the Seq values appear to work correctly. Is it possible to override some Seq values, for instance "last", when the native performance of a value of my collection is better than using Seq's IEnumerable based function? I have not found any information on overriding Seq.
No -- the functions in the Seq module can't be overridden. However, some of them do try to optimize performance by checking their input value (the seq<'T> instance you pass them) to see if it's an instance of IList<'T> or 'T[]; if it is, the functions will take some optimized code path. For example, if you pass an array ('T[]) to Seq.length, it'll be able to quickly determine the length by using the .Length property of arrays.
If you're stuck on using the Seq module, the only performance optimization I can think of would be to have your collection also implement ICollection<'T> and/or IList<'T>. That may optimize some cases, but it won't be all cases.
As already said in the other answer, there is no way you can override the functions in the Seq module. If you're implementing a custom collection, then the best thing to do is to follow the standard pattern used by the core F# libraries.
The Seq module contains the most often used functions and functions that can be reasonably provided for any sequence.
Modules like Array or List provide more efficient implementations for a specific collection type and they add more functions (not available in Seq) that are specific to the collection (for example, functions List.tail and Array.get).
The best way when adding your own collection is to follow this pattern:
Implement IEnumerable<'T> so that the functions from Seq module work for your type
Create MyCollection module that contains efficient implementations of standard functions (at least those that matter to you) and adds more functionality that is specific to your collection.
I have an application that searches files on the computer (configurable path, type etc). Currently it adds information to a database as soon as a matching file is found. Rather than that I want to hold the information in memory for further manipulation before inserting to database. The list may contain a lot of items. I consider performance as important factor. I may need iterating thru the items, so a structure that can be coded easily is another key issue. and how can I achieve php style associative arrays for this job?
If you're using Delphi 2009, you can use a TDictionary. It takes two generic parameters. The first should be a string, for the filename, and the second would be whatever data type you're associating with. It also has three built-in enumerators, one for key-value pairs, one for keys only and one for values only, which makes iterating easy.
Another solution would be to use just a standard TStringList.
As long as it's sorted and has some duplicate setting other than dupAccept, you can use indexof or indexofname to find items in the list quickly.
It also has the Objects addition which allows you to store object information attached to the name. Starting with D2009, TStringList has the OwnsObject property which allows you to delegate object cleanup to the TStringList. Prior to D2009 you have to handle that yourself.
Much of this will depend on how you are going to use the list and to what scale. If you are going to use it as a stack, or queue, then a TList would work fine. If your needing to search through the list for a specific item then you will need something that allows faster retrieval. TDictionary (2009) or TStringList (pre 2009) would be the most likely choice.
Dynamic arrays are also a possiblity, but if you use them you will want to minimize the use of SetLength as each time it is called it will re-allocate memory. TList manages this for you, which is why I suggested using a TList. if you KNOW how many you will deal with in advance, then use a dynamic array, and set its length on the onset.
If you have more items than will fit in memory then your choices also change. At that point I would either use a database table, or a tFileStream to store the records to be processed, then seek to the beginning of the table/stream for processing.
Try using the AVL-Tree by http://sourceforge.net/projects/alcinoe/ as your associative Array. It has an iterate-method for fast iteration. You may need to derive from his baseclass and implement your own comparator, but it's easy to use.
Examples are included.