Ideally when working from an IndexedSeqView over an ArraySeq, there should be only one array copy (or at least only one new array allocated) when converting the view back to an ArraySeq after some manipulation.
What is the most performant way to get back to an ArraySeq?
A couple options that come to mind:
ArraySeq.unsafeWrapArray(view.toArray)
seems promising, but does .toArray know the view is over an array and can use fast array copies to populate the new array?
ArraySeq.from(view)
I'm guessing this is O(n)
The standard way would be
view.to(ArraySeq)
Looking at the documentation, the recommended way is calling view.force to evaluate the transformations for the collection.
Related
I am wondering if the built-in array structure for the contains function has any optimizations. If it does a linear search of contains every time I run it, it's at best O(n), which turns into O(n^2) because I'll be looping through another set of points to check against, however if it somehow behind the scenes sorts the array the first time 'contains' is run, then every subsequent 'contains' would be O(log(n)).
I have an array that gradually gets larger the more in depth the user gets into the application, and I am using the 'contains' a lot, so I am expecting it to slow down the application the longer the user is using the application.
If the array doesn't have any behind the scenes optimizations, then ought I build my own? (e.g. quicksort, and do an insert(newElement:, at:) every time I add to the array?)
Specifically, I'm using
[CGPoint],
CGPointArrayVariable.contains(newCGPoint) // run 100s - 10000s of times ideally every frame, (but realistically probably every second)
and when I add new CGPoints I'm using
CGPointArrayVariable += newCGPointSet.
So, the question: Am I ok continuing to use the built in .contains function (will it be fast enough?) or should I build my own structure optimizing for the contains, and keeping the array sorted? (maybe an insertion sort would be better to use opposed to a quicksort, if that's the direction recommended)
Doing something like that every frame will be VERY inefficient.
I would suggest re-thinking your design to avoid tracking that amount of information for every frame.
If it's absolutely necessary, building your own Type that uses a Dictionary rather than an Array should be more efficient.
Also, if it works with your use case using a Setmight be the best option.
What is an efficient way to get a random element from a collection in Scala? There's a related question here, but like one of the comments pointed out, "[that] question does not specify any efficiency needs".
An arbitrary collection cannot be accessed in constant time. So you need some special collection with the desired property. For instance — Vector or Array. See Performance Characteristics of collections for others.
util.Random.shuffle(List.range(1,100)) take 3
Use a collection with a constant-time size() and get() method.
If you need random order of all collection elements, then Random.shuffle is what you need. (You'd better convert the original collection to array to avoid forward and backward conversion.)
I have a data type called Filter which has an NSMutableArray property which holds a bunch of FilterKey objects (different amount of keys for each filter). I have a bunch of these Filter objects stored in an NSMutableArray called Filters.
I have a UITableView for which each row is populated with data from one of the FilterKey objects. My question is, for a given row in the UITableView, how can I use the Filters array to find the right FilterKey (considering I've already put the Filters and Keys in order manually)?
Basically, I know I could just traverse through the Filters array and for each Filter object, traverse through all it's FilterKeys, but I'm wondering is there a better way to do this (ie better data structure, or something that would give me the right object faster?
Sorry if this is confusing if you have any questions please let me know in the comments.
Typically you would use sections and rows for this, where each section is a Filter and each row is a FilterKey.
It sounds like you just want to show the filter keys, and not have section headers for their filters (if I'm reading your post correctly). If you don't actually want headers, that's fine, just return 0 for tableView:heightForHeaderInSection: and nil for tableView:viewForHeaderInSection:.
All of this is really more for convenience than performance. It is unlikely that it will be much faster than running through the filters and adding up the counts of their keys. That kind of operation is extremely fast. But sections/rows maps your data better, so I'd probably use it anyway to keep the code simpler.
You can use NSMutableDictionary which is hash-mapped resulting in faster, easier, readable operations.
If you prefer arrays then there is no need to traverse to search for a specific value, you can use NSPredicate to filter your array.
This question is about handling arrays of information, there's are many ways I could do this, but I would like some input from programmers with more experience, I know what I want to do just not how to organize the information the best way, and objective-C is really making me ponder this, I don't want to get 100 hours into work a decide, oops this wasted the beast way to do this. So here goes:
I have a grid where I'm simulating a playing field, each piece of the grid I call a cell. The cells have around 20 different values each, all integers, nothing fancy. A change to a cell will be either by player input, or occur or by surrounding cells through different algorithms.
The changes to cells will occur once a turn is complete, so it's not real time. Now, I'm not even sure about doing this with a MutableArrays, a plain Array, or just a plain matrix. Arrays are good at keeping such info for one dimension, but I would imagine would become quite cumbersome if you have to address a batch of 10,000 of these cells. On the other hand a simple matrix might not be so elegant, but probably easier to work with.
Any insight would be greatly appreciated.
You have two options here that I see:
1) Use standard containers
Assuming that the playing field is of constant size, then you can create a mutable array of x*y size, and populate it with mutable dictionaries. By giving everything in the second mutable dictionary keys, you can query and set their properties (all objects of course, so wrap ints in NSNumbers etc). For indexing use a macro INDEX_FROM_ROW_COL(row, col) and apply the appropriate code to multiply/add.
2) Create a helper object subclassed from NSObject. It would manage mutable objects as above, but you could load it with functionality specific to your application. You could provide methods that have parameters of "row:" and "col:". Methods that change or set properties of each cell based on some criteria. Personally, I think this is a better idea as you can incapsulate logic here and make the interface to it more high level. It will make it easier to log whats going on too.
I would appreciate some help with something I working on and have not done before now and having some proplems because I don't think I understand exactly how to do this. What I'm wanting to do i'm sure is simple to most all of you and will be to me as soon as I do it the first time correctly....anyway.... I have a tableview that I'm needing to populate with two things, a username and a number with a count of items (the username could be a primary key). Currently I have a tableview populating and editable with an array....no problem....I know how to do that.
The two parts I need help with understanding is to:
read a plist with these two values into a dictionary, and read them into two different arrays that I can use with my tables.
Save the arrays back to the dictionary and then back to a plist.
I think I'm getting the most confused with how to store these two things in dictonary keys and values. I've looked that over but just not "getting it".
I would appreciate some short code examples of how to do this or a better way to accomplish the same thing.
As always, thanks for your awesome help....
You can use NSArray method writeToFile: atomically: to dump your data into a file, you can then use initWithContentOfFile to retrieve the information from t hat file just as you dumped it previosly. I believe if you have dictionaries in your array you should be able to get them back this way. You can always use core data as well for storage if you find your structures to store are getting complex and dumping the in a file and getting them back to recreate some o bjects is becoming messy.
The approach that would perhaps be the simplest is to store the data as an array of dictionaries. This has the issue that recreating the array from a plist with mutable leaves is convoluted at best.
But if you can tolerate the performance hit of replacing dictionaries when updating the list instead of modifying them, it might definitely be the simplest course of action.
This also has the added benefit that your datasource only needs to deal with one array, and that the whole shebang would be Key-Value Compliant, which might further simplify your code.