search

xxtbg / fseye

Automatically exported from code.google.com/p/fseye
Apache License 2.0
0 stars 0 forks source link

Performance slow when objects that require complex printing are submitted to FSI #14

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Discussion from [Comments]:

Paul: 

Performance seems slow. I'm not sure if I have a problem, but if I start a new 
FSI, and type let z = [1..100];; it can take 5 to 10 seconds before the watch 
appears and FSI returns a prompt? ... Just to add to my previous comment. 
Whereas typing "let z = [1..100];;" can take 10 sec to return if I type 
"eye.Watch("x",[1..100]);;" this always returns instantly.

Stephen:

Regarding performance this is a known issue and is due to the way FsEye? 
discovers all FSI session variables and is notified of new session variables. 
FSI does not expose a rich API for interacting with it. In order to discover 
all the variables in the FSI session we need to use reflection to scan all the 
FSI related dynamic assemblies. While that in itself takes some serious CPU 
cycles, it's sub-second in one pass. However, the only way I am aware of being 
notified that a new variable has been submitted to the FSI session is by adding 
a PrintTransformer? which is notified every-time time an object is printed in 
FSI. Now, for simple objects this is not a problem, since the print transformer 
event is only fired once. However for composite objects like a list of integers 
this can be can harm performance since, for example, [1..100] will trigger the 
event 100 times! I will continue to look into ways to avoid the performance 
issues that arise from this hack. But in the mean-time there is one thing you 
can do: you can tell FSI to limit the number of elements shown in lists using 
fsi.PrintLength, e.g. fsi.PrintLength <- 5 would tell FSI to only print the 
first 5 elements of lists which should lead to a dramatic performance 
improvement since then the print transformer event will only fire 5 times 
instead of 100!

Original issue reported on code.google.com by stephen....@gmail.com on 8 Aug 2011 at 7:27

GoogleCodeExporter commented 9 years ago 
Fixed using nice async hack to turn off the Eye listener temporarily for 100ms 
(non-blocking) when the listener event is first fired.

Original comment by stephen....@gmail.com on 8 Aug 2011 at 7:30

GoogleCodeExporter commented 9 years ago

Original comment by stephen....@gmail.com on 10 Aug 2011 at 4:53

GoogleCodeExporter commented 9 years ago

Original comment by stephen....@gmail.com on 13 Apr 2012 at 6:18