Can you share the code?
If you do the same thing in F# as in C#, you should see roughly the same performance, so this does sound like a data structure/algorithm change. As someone else mentioned, if you switch from C# Lists to F# lists and do appends (@), you will be in trouble, this is a common perf error.
As for diagnosing, given that you have a performant 'reference algorithm' in the C# code, you may just be able to apply various functions to various size data and measure to see e.g. that in the C# version, function Foo is O(N^2) when passed a list of size N, whereas F# function Foo is O(N^3), and use that to narrow down the source of the problem to a particular function. All of the usual strategies for tracking down perf problems in C# should apply to F# as well.
Brian
OK, I've culled the binaries out of the Zip files and am attaching the F# version to this message. C# version to follow in my next posting.
Bill
Can you share the code?
If you do the same thing in F# as in C#, you should see roughly the same performance, so this does sound like a data structure/algorithm change. As someone else mentioned, if you switch from C# Lists to F# lists and do appends (@), you will be in trouble, this is a common perf error.
As for diagnosing, given that you have a performant 'reference algorithm' in the C# code, you may just be able to apply various functions to various size data and measure to see e.g. that in the C# version, function Foo is O(N^2) when passed a list of size N, whereas F# function Foo is O(N^3), and use that to narrow down the source of the problem to a particular function. All of the usual strategies for tracking down perf problems in C# should apply to F# as well.
Brian
Here's the C# version...
Bill
Brian
OK, I've culled the binaries out of the Zip files and am attaching the F# version to this message. C# version to follow in my next posting.
Bill
Can you share the code?
If you do the same thing in F# as in C#, you should see roughly the same performance, so this does sound like a data structure/algorithm change. As someone else mentioned, if you switch from C# Lists to F# lists and do appends (@), you will be in trouble, this is a common perf error.
As for diagnosing, given that you have a performant 'reference algorithm' in the C# code, you may just be able to apply various functions to various size data and measure to see e.g. that in the C# version, function Foo is O(N^2) when passed a list of size N, whereas F# function Foo is O(N^3), and use that to narrow down the source of the problem to a particular function. All of the usual strategies for tracking down perf problems in C# should apply to F# as well.
---
Helium
Strangely your posting (see below) appears to be content free; however the email notification I got of your posting asked about my use of "match" in places where a simple "if" would have worked, so ...
The answer is simply ignorance. At the time I wrote that code I had the impression that all conditionals took a "match" form. Later, when I discovered the existence of "if", I also read that the two forms were "equivalent"; thus didn't bother to change back to if. I agree however that using "if" in these situation does make the code easier to scan. I'll just say in my defense that in my past I wrote a lot of Lisp and Scheme and my previous exposure to "cond" made the use of "match" seem not quite as awkward in these cases.
---
Are there performance penalties associated with using match instead of if? I personally find match statements much easier to read than if statements. In the case where it's equivalent, i.e.
match n with
| 4 -> 0
| _ -> n
you would think the compiler would be smart enough to produce the exact same code as an if statement.
Reflector is an excellent tool if you want to know what code the compiler produces.
F#
1 2 3 4
let f n =
match n with
| 4 -> 0
| _ -> nC#
1 2 3 4 5 6 7 8 9
public static int f(int n)
{
switch (n)
{
case 4:
return 0;
}
return n;
}Here is one huge bit; I did not look for others.
1 2 3 4 5 6 7 8 9 10
// you had this, .RowColumns re-evaluates a Seq and ToArrays it every time
type Puzzle() =
static member PuzzleSize = 4
static member RowColumns = [| for r in 0 .. Puzzle.PuzzleSize - 1 do for c in 0 .. Puzzle.PuzzleSize - 1 -> (r, c) |]
// change to this, only evals once
type Puzzle() =
static let rc = [| for r in 0 .. Puzzle.PuzzleSize - 1 do for c in 0 .. Puzzle.PuzzleSize - 1 -> (r, c) |]
static member PuzzleSize = 4
static member RowColumns = rcBTW, I found this just by running in the debugger and hitting 'break all' a few times and noticing I was always inside Puzzle.RowColumns inside LowerBoundOnScore.
Brian
I made the suggested change, not only for the PuzzleSize property, but for the other static properties as well. Making these changes brings the GC counts back into the same neighborhood as the C# version (in fact slightly better than the C# version.) Unfortunately the performance is still significantly worse in the F# version. I'm attaching my spreadsheet which shows the performance and GC activity for each version. The topmost F# version (revision 1759) reflects the described changes.
Since <i>LowerBoundOnScore<i> appears to be the hotspot I'm guessing that my recasting of that into a more functional form (using Seq.fold and a functional arg for the scoring strategy) may be introducing overhead relative to the original C# version (within which the 2 strategies are hard coded with some what-if-yes-but code logic.) Anyway, that'll be my next attempt at isolating the difference. Thanks again for the help in observing the "implicit get" problem. I could have stared at that code forever and wouldn't have discoverd that! Bill <quote> Here is one huge bit; I did not look for others. ... </quote>
Brian
Thanks; however this is confusing to me. That RowColumns is reevaluated each time it is referenced implies that RowColumns is a function value, but it is typed (by the F# compiler) as (int * int) [] which is not a function. So, what am I missing?
BTW, LowerBoundOnScore is in fact the "hotspot" for this algorithm in the C# version so I'm not surprised that it appears to be in the F# as well. This doesn't address the consing however. Perhaps I've misunderstood something about RowDolumns though. I'll do some experimenting.
[Added later] I've tried your suggestion and it does help quite a bit -- so I remain confused. What am I missing on the static member evaluation?
Bill
Here is one huge bit; I did not look for others.
1 2 3 4 5 6 7 8 9 10// you had this, .RowColumns re-evaluates a Seq and ToArrays it every time type Puzzle() = static member PuzzleSize = 4 static member RowColumns = [| for r in 0 .. Puzzle.PuzzleSize - 1 do for c in 0 .. Puzzle.PuzzleSize - 1 -> (r, c) |] // change to this, only evals once type Puzzle() = static let rc = [| for r in 0 .. Puzzle.PuzzleSize - 1 do for c in 0 .. Puzzle.PuzzleSize - 1 -> (r, c) |] static member PuzzleSize = 4 static member RowColumns = rcBTW, I found this just by running in the debugger and hitting 'break all' a few times and noticing I was always inside Puzzle.RowColumns inside LowerBoundOnScore.
It's a property (with an implicit getter).
1 2 3 4 5 6 7 8 9
type Foo() =
static member SomeProp =
printfn "hi"
42
let a = Foo.SomeProp
let b = Foo.SomeProp
let c = Foo.SomeProp
printfn "done"Brian
Thanks for the explanation. Now I understand. I really missed the "implicit getter" thing entirely. I think I'm still going to have a large difference between the c# and f# versions, but this'll help a lot.
Thanks again,
Bill
It's a property (with an implicit getter).
1 2 3 4 5 6 7 8 9type Foo() = static member SomeProp = printfn "hi" 42 let a = Foo.SomeProp let b = Foo.SomeProp let c = Foo.SomeProp printfn "done"
BTW, the "member x.Foo = .." syntax for writing properties is actually a shorthand for writing the following:
1 2 3 4 5
type A() =
member x.Foo with get() =
printfn "hello..."
42This should explain the behavior you're seeing!
Brian
OK, so here's the code. There are 2 zip files, each a complete folder structure from a VS2008 solution. The P1 version is the F# version. If you look in the performance.xlsx spreadsheet (in the P1 version) you'll see the comparative runtimes (in ms) and gc counts for each collector generation. The timing and gc differences are pretty dramatic, more than 10x.
OOPS! Apparently there's a 64K limit on uploads so I can't upload either of the Zip files. Each zip is ~310K in size. If you'll send a private message with your email address I can send 'em that way.
Regards,
Bill
Can you share the code?
...
310k is pretty heavy for a bunch of compressed text files. Did you include any of the binaries VS generates when you build? output EXE, PDB, etc? Another thing that would be useful is to comment out certain areas of the code, or certain features of the algorithm, and watch how memory usage changes. Then you can pinpoint what part of the algorithm is causing it, and you'd only have to post a small code fragment that reproduces the problem.
Good point. I'll check the zip files as they probably do contain some binaries. As for commenting out parts of the algorithm I'll think about that, but it's difficult because it's a tree search.
Bill
310k is pretty heavy for a bunch of compressed text files. Did you include any of the binaries VS generates when you build? output EXE, PDB, etc? Another thing that would be useful is to comment out certain areas of the code, or certain features of the algorithm, and watch how memory usage changes. Then you can pinpoint what part of the algorithm is causing it, and you'd only have to post a small code fragment that reproduces the problem.
Brian
Yes I can share the code. Should I just post it as an attachment here or is it better to email it? Either is fine with me. BTW, I don't do any @, just ::
FYI, the puzzle in question is called "NPuzzle" and is the N x N (typically N = 4) puzzle consisting of NxN-1 numbered tiles in a frame. The object is to sort the tiles by sliding tiles into the empty space. The goal is to do the sort with a minimum number of such "moves". So, in the abstract this is just a (very large) game tree problem and one can (in theory) walk the entire tree and pick the shortest path from root to leaf as the solution. There are several refinements that limit the tree search and allow for much more efficient solution. These are in the form of "scoring" algorithms that allow you to get a lower bound on a solution from any node of the game tree.
Thanks,
Bill
Can you share the code?
If you do the same thing in F# as in C#, you should see roughly the same performance, so this does sound like a data structure/algorithm change. As someone else mentioned, if you switch from C# Lists to F# lists and do appends (@), you will be in trouble, this is a common perf error.
As for diagnosing, given that you have a performant 'reference algorithm' in the C# code, you may just be able to apply various functions to various size data and measure to see e.g. that in the C# version, function Foo is O(N^2) when passed a list of size N, whereas F# function Foo is O(N^3), and use that to narrow down the source of the problem to a particular function. All of the usual strategies for tracking down perf problems in C# should apply to F# as well.
Yes you are perfectly right - the @ - Operator is a performance killer (as far as I know this is no big brainer - a C# List is build as a linked list so consing is a O(1) Operation - F# lists are of the form (head, tail) where tail is another list - so in order to cons a element you have to iterate through both lists again)
So either try avoiding the @ in performance crticial places (i.e. the inner loops etc.) by building up your lists with :: recursivly or switch in your algorithms to the C# System.Collection.Generic.List. Or think again about your algorithm and try identifing the right datastructures for it (for example when you use @ often a binary tree might be better suited - or a (Hash-)set that is using this structure).
Greetings.
I'm not sure to which type you are referring when you say a "C# List", but the list types in the .Net framework appear to be singly or doubly linked lists. The F# list is singly linked (I assume); thus the :: operator should be O(1) and should not involve any copying at all. It will of course cause a single (head,tail) pair to be allocated on the heap.
The append (@) operator will cause copying of the left argument; however my algorithm doesn't use the @ operator at all, just ::
Yes you are perfectly right - the @ - Operator is a performance killer (as far as I know this is no big brainer - a C# List is build as a linked list so consing is a O(1) Operation - F# lists are of the form (head, tail) where tail is another list - so in order to cons a element you have to iterate through both lists again)
...
You're right, like I mentioned you can even prove to yourself that there's no copying going on with a cons (via List.Cons, or the :: operator) by using Object.ReferenceEquals. Are you using a deep recursion anywhere that is not tail recursive? It's hard to make conjectures with no code sample. I've done a number of comparisons myself and the performance has always been good with F#.
Divisor
Yes, the algorithm does do deep recursion that is not tail recursive; however that is true of both the c# and the f# implementations. The algorithm is basically searching a "game tree"; thus the recursion. Deep recursion shouldn't by itself cause a lot of consing, right? Unless f# frames are heap allocated?
I'll be posting the code here some time today.
Bill
You're right, like I mentioned you can even prove to yourself that there's no copying going on with a cons (via List.Cons, or the :: operator) by using Object.ReferenceEquals. Are you using a deep recursion anywhere that is not tail recursive? It's hard to make conjectures with no code sample. I've done a number of comparisons myself and the performance has always been good with F#.
Bill,
some data structures in F# are immutable (list<'a> for example). So every time you operate on these structures you need to create copies, a thing you can often avoid in C#.
So the overhead from copying data around could be a cause of performace degradation. Just a guess.
I haven't tried before on F#, but I think you could do some profiling with standard .NET tools. DotTrace Profiler is a great tool, but it ain't free.
Hope it helps
Mau
Thanks for the response; however I don't believe that the :: operator causes any copying. I would assume that it allocates storage for the new list head element, but it certainly does not copy the tail of the list. Why would it?
As for profiling, I wasn't aware that these tools gave you info on heap allocation and GC. Is that the case? That'd be good news!
Regards,
Bill
While true, it's not quite as bad as it sounds. For example, try the following at the FSI prompt:
> let x = [1; 2; 3; 4; 5];;
val x : int list = [1; 2; 3; 4; 5]
> let y = 0 :: x;;
val y : int list = [0; 1; 2; 3; 4; 5]
> Object.ReferenceEquals((box x.Tail), (box y.Tail.Tail));;
(no F# compiler on the computer i'm typing from atm, but if the syntax is incorrect, it should be trivial to fix).
the result of the above expression will be true. So while while yes there's copying going on, the fact that data structures are immutable means that most of the time it's the reference that's being copied, not the entire contents of the object. If data structures were mutable, this would obviously have devastating results. But since they're not, it's ok. For some reason I doubt that excessive cons'ing is causing a serious performance problem, although I could always be wrong. Code samples would help though.
Topic tags
- f# × 3705
- websharper × 1897
- compiler × 286
- functional × 201
- ui next × 139
- c# × 121
- classes × 97
- web × 97
- .net × 84
- book × 84
- async × 76
- ui.next × 67
- bug × 54
- core × 49
- website × 49
- server × 45
- parallel × 43
- ui × 43
- enhancement × 41
- parsing × 41
- testing × 41
- trywebsharper × 41
- typescript × 37
- html × 35
- javascript × 35
- owin × 35
- asynchronous × 30
- monad × 28
- ocaml × 28
- tutorial × 27
- warp × 27
- haskell × 26
- sitelet × 25
- linq × 22
- workflows × 22
- wpf × 20
- fpish × 19
- introduction × 19
- silverlight × 19
- sitelets × 19
- monodevelop × 17
- rpc × 17
- suave × 17
- piglets × 16
- collections × 15
- feature request × 15
- jquery × 15
- templates × 15
- getting started × 14
- pipeline × 14
- kendoui × 13
- reactive × 12
- 4.1.0.171 × 11
- monads × 11
- opinion × 10
- 4.0.190.100-rc × 9
- deployment × 9
- fixed × 9
- formlets × 9
- in × 9
- json × 9
- plugin × 9
- proposal × 9
- scheme × 9
- solid × 9
- basics × 8
- concurrent × 8
- highcharts × 8
- how-to × 8
- python × 8
- 4.1.1.175 × 7
- complexity × 7
- documentation × 7
- visual studio × 7
- 4.1.2.178 × 6
- lisp × 6
- real-world × 6
- released in 4.0.192.103-rc × 6
- remoting × 6
- resources × 6
- scala × 6
- websharper ui.next × 6
- workshop × 6
- xaml × 6
- 4.0.193.110 × 5
- 4.2.3.236 × 5
- aspnetmvc × 5
- authentication × 5
- azure × 5
- bootstrap × 5
- conference × 5
- dsl × 5
- formlet × 5
- java × 5
- list × 5
- metaprogramming × 5
- ml × 5
- released in Zafir.4.0.188.91-beta10 × 5
- sql × 5
- visualstudio × 5
- websharper.forms × 5
- zafir × 5
- 4.0.192.106 × 4
- 4.0.195.127 × 4
- 4.1.0.38 × 4
- 4.2.1.86 × 4
- 4.2.6.118 × 4
- css × 4
- example × 4
- extensions × 4
- fsi × 4
- fsx × 4
- html5 × 4
- jqueryui × 4
- lift × 4
- reflection × 4
- remote × 4
- rest × 4
- spa × 4
- teaching × 4
- template × 4
- websocket × 4
- wontfix × 4
- 4.0.196.147 × 3
- 4.1.0.34 × 3
- 4.1.6.207 × 3
- 4.2.1.223-beta × 3
- 4.2.11.258 × 3
- 4.2.4.114 × 3
- 4.2.4.247 × 3
- 4.2.5.115 × 3
- 4.2.6.253 × 3
- 4.2.9.256 × 3
- ajax × 3
- alt.net × 3
- aml × 3
- asp.net mvc × 3
- canvas × 3
- cloudsharper × 3
- compilation × 3
- database × 3
- erlang × 3
- events × 3
- extension × 3
- file upload × 3
- forums × 3
- inline × 3
- issue × 3
- kendo × 3
- macro × 3
- mono × 3
- msbuild × 3
- mvc × 3
- pattern × 3
- piglet × 3
- released in Zafir.4.0.187.90-beta10 × 3
- svg × 3
- type provider × 3
- view × 3
- 4.1.1.64 × 2
- 4.1.5.203 × 2
- 4.1.7.232 × 2
- 4.2.10.257 × 2
- 4.2.3.111 × 2
- 4.2.5.249 × 2
- android × 2
- asp.net × 2
- beginner × 2
- blog × 2
- chart × 2
- client × 2
- client server app × 2
- clojure × 2
- computation expressions × 2
- constructor × 2
- corporate × 2
- courses × 2
- cufp × 2
- d3 × 2
- debugging × 2
- direct × 2
- discriminated union × 2
- docs × 2
- elm × 2
- endpoint × 2
- endpoints × 2
- enterprise × 2
- entity framework × 2
- event × 2
- f# interactive × 2
- fable × 2
- flowlet × 2
- formdata × 2
- forms × 2
- fsc × 2
- google maps × 2
- hosting × 2
- http × 2
- https × 2
- iis 8.0 × 2
- install × 2
- interactive × 2
- interface × 2
- iphone × 2
- iteratee × 2
- jobs × 2
- jquery mobile × 2
- keynote × 2
- lens × 2
- lenses × 2
- linux × 2
- listmodel × 2
- mac × 2
- numeric × 2
- oauth × 2
- obfuscation × 2
- offline × 2
- oop × 2
- osx × 2
- packaging × 2
- pattern matching × 2
- performance × 2
- pipelines × 2
- q&a × 2
- quotation × 2
- reference × 2
- released in Zafir.4.0.185.88-beta10 × 2
- rx × 2
- script × 2
- security × 2
- self host × 2
- seq × 2
- sockets × 2
- stm × 2
- tcp × 2
- trie × 2
- tutorials × 2
- type × 2
- url × 2
- var × 2
- websharper.charting × 2
- websharper4 × 2
- websockets × 2
- wig × 2
- xna × 2
- zh × 2
- .net interop × 1
- 2012 × 1
- 4.0.194.126 × 1
- 4.1.3.184 × 1
- 4.1.4.189 × 1
- 4.2.0.214-beta × 1
- 4.2.12.259 × 1
- 4.2.2.231-beta × 1
- 4.2.8.255 × 1
- Canvas Sample Example × 1
- DynamicStyle Animated Style × 1
- Fixed in 4.0.190.100-rc × 1
- Released in Zafir.UI.Next.4.0.169.79-beta10 × 1
- SvgDynamicAttribute × 1
- WebComponent × 1
- abstract class × 1
- accumulator × 1
- active pattern × 1
- actor × 1
- addin × 1
- agents × 1
- aggregation × 1
- agile × 1
- alter session × 1
- animation × 1
- anonymous object × 1
- apache × 1
- api × 1
- appcelerator × 1
- architecture × 1
- array × 1
- arrays × 1
- asp.net 4.5 × 1
- asp.net core × 1
- asp.net integration × 1
- asp.net mvc 4 × 1
- asp.net web api × 1
- aspnet × 1
- ast × 1
- attributes × 1
- authorization × 1
- b-tree × 1
- back button × 1
- badimageformatexception × 1
- bash script × 1
- batching × 1
- binding-vars × 1
- bistro × 1
- body × 1
- bundle × 1
- camtasia studio × 1
- cas protocol × 1
- charts × 1
- clarity × 1
- class × 1
- cli × 1
- clipboard × 1
- clojurescript × 1
- closures × 1
- cloud × 1
- cms × 1
- coding diacritics × 1
- color highlighting × 1
- color zones × 1
- combinator × 1
- combinators × 1
- compile × 1
- compile code on server × 1
- config × 1
- confirm × 1
- content × 1
- context × 1
- context.usersession × 1
- continuation-passing style × 1
- coords × 1
- cordova × 1
- cors × 1
- coursera × 1
- cross-domain × 1
- csla × 1
- current_schema × 1
- custom content × 1
- data × 1
- data grid × 1
- datetime × 1
- debug × 1
- declarative × 1
- delete × 1
- devexpress × 1
- dhtmlx × 1
- dictionary × 1
- directattribute × 1
- disqus × 1
- distance × 1
- do binding × 1
- doc elt ui.next upgrade × 1
- docker × 1
- dojo × 1
- dol × 1
- dom × 1
- domain × 1
- du × 1
- duf-101 × 1
- dynamic × 1
- eastern language × 1
- eclipse × 1
- edsl × 1
- em algorithm × 1
- emacs × 1
- emotion × 1
- enums × 1
- error × 1
- etw × 1
- euclidean × 1
- eventhandlerlist × 1
- examples × 1
- ext js × 1
- extension methods × 1
- extra × 1
- facet pattern × 1
- failed to translate × 1
- fake × 1
- fantomas × 1
- fear × 1
- float × 1
- form × 1
- form-data × 1
- forum × 1
- fp × 1
- frank × 1
- fsdoc × 1
- fsharp × 1
- fsharp.core × 1
- fsharp.powerpack × 1
- fsharpx × 1
- fsunit × 1
- function × 1
- functional style × 1
- game × 1
- games × 1
- gc × 1
- generic × 1
- geometry × 1
- getlastwin32error × 1
- getting-started × 1
- google × 1
- google.maps × 1
- grid × 1
- group × 1
- guide × 1
- hash × 1
- headers × 1
- hello world example × 1
- heroku × 1
- highchart × 1
- history × 1
- how to × 1
- html-templating × 1
- http405 × 1
- httpcontext × 1
- hubfs × 1
- i18n × 1
- ie 8 × 1
- if-doc × 1
- iis × 1
- image × 1
- images × 1
- inheritance × 1
- initialize × 1
- input × 1
- install "visual studio" × 1
- installer × 1
- int64 × 1
- interfaces × 1
- internet explorer × 1
- interop × 1
- interpreter × 1
- io × 1
- iobservable × 1
- ios × 1
- iot × 1
- ipad × 1
- isomorphic × 1
- javascript optimization × 1
- javascript semanticui resources × 1
- jquery-plugin × 1
- jquery-ui × 1
- jquery-ui-datepicker × 1
- js × 1
- kendo datasource × 1
- kendochart × 1
- kendoui compiler × 1
- knockout × 1
- l10n × 1
- learning × 1
- library × 1
- libs × 1
- license × 1
- licensing × 1
- lineserieszonescfg × 1
- local setting × 1
- localization × 1
- logging × 1
- loop × 1
- macros × 1
- mailboxprocessor × 1
- mapping × 1
- maps × 1
- markerclusterer × 1
- markup × 1
- marshal × 1
- math × 1
- mathjax × 1
- message × 1
- message passing × 1
- message-passing × 1
- meta × 1
- metro style × 1
- micro orm × 1
- minimum-requirements × 1
- mix × 1
- mobile installation × 1
- mod_mono × 1
- modal × 1
- module × 1
- mouseevent × 1
- mouseposition × 1
- multidimensional × 1
- multiline × 1
- multithreading × 1
- mysql × 1
- mysqlclient × 1
- nancy × 1
- native × 1
- nested × 1
- nested loops × 1
- node × 1
- nunit × 1
- object relation mapper × 1
- object-oriented × 1
- om × 1
- onboarding × 1
- onclick × 1
- optimization × 1
- option × 1
- orm × 1
- os x × 1
- output-path × 1
- override × 1
- paper × 1
- parameter × 1
- persistence × 1
- persistent data structure × 1
- phonegap × 1
- pola × 1
- post × 1
- powerpack × 1
- prefix tree × 1
- principle of least authority × 1
- privacy × 1
- private × 1
- profile × 1
- programming × 1
- project × 1
- project euler × 1
- projekt_feladat × 1
- protected × 1
- provider × 1
- proxy × 1
- ptvs × 1
- public × 1
- pure f# × 1
- purescript × 1
- qna × 1
- quant × 1
- query sitelet × 1
- question × 1
- quotations × 1
- range × 1
- raphael × 1
- razor × 1
- rc × 1
- reactjs × 1
- real-time × 1
- ref × 1
- region × 1
- released in 4.0.190.100-rc × 1
- reporting × 1
- responsive design × 1
- rest api × 1
- rest sitelet × 1
- restful × 1
- round table × 1
- router × 1
- routing × 1
- rpc reverseproxy × 1
- runtime × 1
- sales × 1
- sample × 1
- sampleapp × 1
- scriptcs × 1
- scripting × 1
- search × 1
- self hosted × 1
- semanticui × 1
- sequence × 1
- serialisation × 1
- service × 1
- session-state × 1
- sharepoint × 1
- signals × 1
- sitelet website × 1
- sitelet.protect × 1
- sitlets × 1
- slickgrid × 1
- source code × 1
- sqlentityconnection × 1
- ssl × 1
- standards × 1
- static content × 1
- stickynotes × 1
- streamreader × 1
- stress × 1
- strong name × 1
- structures × 1
- submitbutton × 1
- subscribe × 1
- svg example html5 websharper.ui.next × 1
- sweetalert × 1
- system.datetime × 1
- system.reflection.targetinvocationexception × 1
- table storage × 1
- targets × 1
- tdd × 1
- templates ui.next × 1
- templating × 1
- text parsing × 1
- three.js × 1
- time travel × 1
- tls × 1
- tooltip × 1
- tracing × 1
- tsunamiide × 1
- turkish × 1
- twitter-bootstrap × 1
- type erasure × 1
- type inference × 1
- type providers × 1
- type-providers × 1
- typeprovider × 1
- ui next forms × 1
- ui-next × 1
- ui.next jqueryui × 1
- ui.next charting × 1
- ui.next formlets × 1
- ui.next forms × 1
- ui.next suave visualstudio × 1
- ui.next templating × 1
- unicode × 1
- unittest client × 1
- upload × 1
- usersession × 1
- validation × 1
- vb × 1
- vb.net × 1
- vector × 1
- view.map × 1
- visal studio × 1
- visual f# × 1
- visual studio 11 × 1
- visual studio 2012 × 1
- visual studio shell × 1
- vs2017 compiler zafir × 1
- vsix × 1
- web api × 1
- web-scraping × 1
- webapi × 1
- webcomponents × 1
- webforms × 1
- webgl × 1
- webrtc × 1
- webshaper × 1
- websharper async × 1
- websharper codemirror × 1
- websharper f# google × 1
- websharper forms × 1
- websharper reactive × 1
- websharper rpc × 1
- websharper sitelets routing × 1
- websharper warp × 1
- websharper-interface-generator × 1
- websharper.chartsjs × 1
- websharper.com × 1
- websharper.exe × 1
- websharper.owin × 1
- websharper.ui.next × 1
- websharper.ui.next jquery × 1
- websockets iis × 1
- why-websharper × 1
- windows 7 × 1
- windows 8 × 1
- windows-phone × 1
- winrt × 1
- www.grabbitmedia.com × 1
- xamarin × 1
- xml × 1
- yeoman × 1
- yield × 1
- zafir beta × 1
- zafir websharper4 × 1
- zarovizsga × 1
|
Copyright (c) 2011-2012 IntelliFactory. All rights reserved. Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy |
Built with WebSharper |
I am evaluating F# and am using a Puzzle solving app written in C# as a benchmark. I've translated the C# version into F# making only a few changes -- mostly to get rid of mutated variables. The data structures themselves are pretty much the same; i.e., linked lists, fixed length arrays. I also converted one c# class into a tuple since it was small and had no non data members.
What I'm seeing is that the F# version performs MUCH MUCH worse than the c# version. What appears to be an (the? underlying cause is the order of magnitude increase in GCs when the f# version runs. It's not clear (to me) what particular F# constructs are contributing to this, but the increase is so dramatic that I'm hoping I'm just doing something stupid.
So, my question is, how might I go about isolating the source of all this consing -- or am I simply doomed to take the performance hit so that I might enjoy the functional approach?
Thanks in advance,
Bill