Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Edit:</strong> I was wrong, it's not a question of value type vs reference type. The performance problem was related to the hash function, as explained in other comments. I keep my answer here because there's an interessant discussion. My code partially fixed the performance issue, but this is not the clean and recommended solution.</p> <p>--</p> <p>On my computer, I made your sample run <em>twice as fast</em> by replacing the tuple with a struct. This means, the equivalent F# code should run faster than your Python code. I don't agree with the comments saying that .NET hashtables are slow, I believe there's no significant difference with Python or other languages implementations. Also, I don't agree with the "You can't 1-to-1 translate code expect it to be faster": F# code will generally be faster than Python for most tasks (static typing is very helpful to the compiler). In your sample, most of the time is spent doing hashtable lookups, so it's fair to imagine that both languages <em>should</em> be almost as fast.</p> <p>I think the performance issue is related to gabage collection (but I haven't checked with a profiler). The reason why using tuples can be slower here than structures has been discussed in a SO question ( <a href="https://stackoverflow.com/questions/2410710/why-is-the-new-tuple-type-in-net-4-0-a-reference-type-class-and-not-a-value-ty">Why is the new Tuple type in .Net 4.0 a reference type (class) and not a value type (struct)</a>) and a MSDN page (<a href="http://msdn.microsoft.com/en-us/magazine/dd942829.aspx#id0400060" rel="nofollow noreferrer">Building tuples</a>):</p> <blockquote> <p>If they are reference types, this means there can be lots of garbage generated if you are changing elements in a tuple in a tight loop. [...] F# tuples were reference types, but there was a feeling from the team that they could realize a performance improvement if two, and perhaps three, element tuples were value types instead. Some teams that had created internal tuples had used value instead of reference types, because their scenarios were very sensitive to creating lots of managed objects.</p> </blockquote> <p>Of course, as Jon said in another comment, the obvious optimization in your example is to replace hashtables with arrays. Arrays are obviously much faster (integer index, no hashing, no collision handling, no reallocation, more compact), but this is very specific to your problem, and it doesn't explain the performance difference with Python (as far as I know, Python code is using hashtables, not arrays).</p> <p>To reproduce my 50% speedup, here is the full code: <a href="http://pastebin.com/nbYrEi5d" rel="nofollow noreferrer">http://pastebin.com/nbYrEi5d</a></p> <p>In short, I replaced the tuple with this type:</p> <pre><code>type Tup = {x: int; y: int} </code></pre> <p>Also, it seems like a detail, but you should move the <code>List.mapi (fun i x -&gt; (i,x)) fileSizes</code> out of the enclosing loop. I believe Python <code>enumerate</code> does not actually allocate a list (so it's fair to allocate the list only once in F#, or use <code>Seq</code> module, or use a mutable counter).</p>
    singulars
    1. This table or related slice is empty.
    1. POFSharp runs my algorithm slower than Python
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USLaurent
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COAbout your List.mapi comment: I did try my own "seq"-based enumerate: let enumerate c = seq { let idx = ref 0 for elem in c do yield (!idx, elem) idx := !idx + 1 } ... but it had no impact - speed was still slow. As I said above, turns out the culprit is the bad performance of .NET Dictionary...
      singulars
      1. PO
      1. USttsiodras
    2. CO@ttsiodras: I don't think so. With my change, the code is a bit faster than the Python implementation, this means dictionaries are not that slow in .NET. Of course, arrays are much faster than hashtables when you know the index, but you're changing the algorithm.
      singulars
      1. PO
      1. USLaurent
    3. COAnd for the `mapi`, I think it's a detail and it won't change the speed much. That said, please avoid the "ref" type when you can (`mutable` is much faster). Here, you could use `Seq.mapi` (but I think moving `List.mapi` out of the loop is a better idea).
      singulars
      1. PO
      1. USLaurent
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload