Why is ReactiveList with ChangeTrackingEnabled slow when I Clear inside SuppressChangeNotifications?
With 10,000 entries it takes about 2 seconds for the Clear method to return.
Shouldn't SuppressChangeNotifications bypass the change tracking code?
Or how can I improve the performance here?
ReactiveList<Person> _personList = new ReactiveList<Person> { ChangeTrackingEnabled = true };
using (_personList.SuppressChangeNotifications())
{
_personList.Clear();
}
Thanks a lot.
Change tracking code is bypassed, but still ReactiveList needs to cleanup its internal stuff when you clear the list. And the method used to do so is extremely inefficient ( O(n2) ), as detailed in this SO answer.
The Clear implementation with change tracking enabled can definitely be improved, I'll send a PR to RxUI if I get the chance.
E.g. replacing this code by foreach (var foo in _propertyChangeWatchers.Values.ToList()) foo.Release(); makes the Clear immediate, w/o altering the behavior.
EDIT :
You can work around this performance issue by writing instead:
using (_personList.SuppressChangeNotifications())
_personList.RemoveRange(0, _personList.Count);
Related
private void LookAtMouse()
{
if (Physics.Raycast(mainCamera.ScreenPointToRay(mouseLook), out var raycastHit, Mathf.Infinity))
{
_direction = (raycastHit.point - transform.position).normalized;
_direction.y = 0;
transform.forward = _direction;
}
}
whenever I call this function in update it kills my movement. If I don't run this function everything works perfectly. I have tried using transform.LookAt() I tried using transform.Translate() in movement, Rigidbody.MovePosition(), changing anything else doesn't help.
If I comment out the transform.forward = _direction; then everything works perfect. what is it about that that makes my movement run game breakingly slow
I have tried every possible thing I can find online to fix this and nothing has been helping.
As soon as any physics is involved you do not want to set things via Transform as this breaks the physics and collision detection.
You should be using Rigidbody.MoveRotation in combination with Quaternion.LookRotation within FixedUpdate
Try to call it in FixedUpdate
generally, I use Update just for catching Key input because it may be called +1000 time if your device is powerful, in the other hand fixed update is better to do the physics .iv it a try and replay if it didn't help to think in other solution;
class A {
has $.n;
# If this method is uncommented then the clone won't be sunk
# method clone {
# my $clone = callwith(|%_);
# return $clone;
# }
method sink(-->Nil) { say "sinking...$!n" }
}
sub ccc(A:D $a) { $a.clone(n=>2) }
ccc(A.new(n=>1));
say 'Done';
Above prints:
sinking...2
Done
However, if the custom clone method is used, then the returned clone from ccc won't be sunk for some reason. It works if I sink it explicitly at call site or if I change the my $clone = callwith(|%_) line to my $clone := callwith(|%_). Is this expected? What's the reason that it's working this way?
Thanks!
There are lots of filed-and-still-open-years-later sink bugs (and, I suspect, loads that have not been filed).
As touched on in my answer to Last element of a block thrown in sink context:
someone needs to clean the kitchen sink, i.e. pick up where Zoffix left off with his Flaws in implied sinkage / &unwanted helper issue.
Zoffix's conclusion was:
So given there are so many issues with the system, I'm just wondering if there isn't a better one that can be used to indicate whether something is wanted or not.
Fast forward 2 years, and a better system is hopefully going to land. In a recent grant report jnthn writes:
The current code doing this work in Rakudo is difficult to follow and not terribly efficient. ... Since RakuAST models the language at a higher level and defers producing QAST until much later, a far cleaner solution to the sink analysis problem is possible. ... I'm optimistic that the model I've created will be flexible enough to handle all the sinking-related requirements
I'm not sure what is going on yet, but removing the return statement makes the cloned object call the right sink method.
I've created an issue for it: https://github.com/rakudo/rakudo/issues/3855
A ZVAL is typically created with emalloc so it is destroyed at the end of a page request. Is there a way to take an existing ZVAL and make it persist in the SAPI (equivalent of pemalloc)? What about creating a ZVAL with pemalloc?
Ideally what I'd like to do (in PHP code) is this:
class Object
{
public $foo;
}
if(!($object = persist("object")))
{
$object = persist("object", new Object());
}
$object->foo[] = "bar";
print count($object->foo);
On each request count would return +1 (assuming the same PHP "worker" is used every time - I'm using PHP-FPM).
You're basically describing http://lxr.php.net/opengrok/xref/PHP_5_3/ext/sysvshm/sysvshm.c#242
The closest you can get without duplicating functionality which is already in shm is https://github.com/flavius/php-persist. The catch: in a prefork/multiprocess SAPI (like apache's), different requests from the same client may end up in different processes, and as such, you'll see different data (try it on Linux + Firefox with a hard refresh every time in the browser).
Note: It's a work-in-progress, currently it persists only an integer. Adding an array should be trivial. Patches welcome. It still needs the deserialization part, and to actually use persist()'s first parameter.
zend_object can't be persisent therefore you can't do this. extensions like APC serializes the object into memory.
Even though I've been using mootools for a while now, I haven't really gotten into playing with the natives yet. Currently I'm trying to extend events by adding a custom addEvent method beside the original. I did that using the following code(copied from mootools core)
Native.implement([Element, Window, Document], {
addMyEvent:function(){/* code here */}
}
Now the problem is that I can't seem to figure out, how to properly overwrite the existing fireEvent method in a way that I can still call the orignal method after executing my own logic.
I could probably get the desired results with some ugly hacks but I'd prefer learning the elegant way :)
Update: Tried a couple of ugly hacks. None of them worked. Either I don't understand closures or I'm tweaking the wrong place. I tried saving Element.fireEvent to a temporary variable(with and without using closures), which I would then call from the overwritten fireEvent function(overwritten using Native.implement - the same as above). The result is an endless loop with fireEvent calling itself over and over again.
Update 2:
I followed the execution using firebug and it lead me to Native.genericize, which seems to act as a kind of proxy for the methods of native classes. So instead of referencing the actual fireEvent method, I referenced the proxy and that caused the infinite loop. Google didn't find any useful documentation about this and I'm a little wary about poking around under the hood when I don't completely understand how it works, so any help is much appreciated.
Update 3 - Original problem solved:
As I replied to Dimitar's comment below, I managed to solve the original problem by myself. I was trying to make a method for adding events that destroy themselves after a certain amount of executions. Although the original problem is solved, my question about extending natives remain.
Here's the finished code:
Native.implement([Element, Window, Document], {
addVolatileEvent:function(type,fn,counter,internal){
if(!counter)
counter=1;
var volatileFn=function(){
fn.run(arguments);
counter-=1;
if(counter<1)
{
this.removeEvent(type,volatileFn);
}
}
this.addEvent(type,volatileFn,internal);
}
});
is the name right? That's the best I could come up with my limited vocabulary.
document.id("clicker").addEvents({
"boobies": function() {
console.info("nipple police");
this.store("boobies", (this.retrieve("boobies")) ? this.retrieve("boobies") + 1 : 1);
if (this.retrieve("boobies") == 5)
this.removeEvents("boobies");
},
"click": function() {
// original function can callback boobies "even"
this.fireEvent("boobies");
// do usual stuff.
}
});
adding a simple event handler that counts the number of iterations it has gone through and then self-destroys.
think of events as simple callbacks under a particular key, some of which are bound to particular events that get fired up.
using element storage is always advisable if possible - it allows you to share data on the same element between different scopes w/o complex punctures or global variables.
Natives should not be modded like so, just do:
Element.implement({
newMethod: function() {
// this being the element
return this;
}
});
document.id("clicker").newMethod();
unless, of course, you need to define something that applies to window or document as well.
I have a coworker who's written the following line in the page load method in an aspx page:
myDataSet = (DataSet)HttpContext.Current.Cache["dataset"];
The first time I hit the page HttpContext.Current.Cache["dataset"] reads null. When he does it, the value is "" (string.Empty) and he gets a cast exception.
We're both running ASP.Net 2.0 on our development machines, he's cleared his browser cache and run an iisreset, yet that thing still reads "" the first time he hits the page. Does anyone have ideas on what we can check to explain this discrepancy?
Try this instead for now, you'll at least avoid hitting the exception:
myDataSet = HttpContext.Current.Cache["dataset"] as DataSet;
I'd search your code and see what is actually assigning "dataset" into the cache. Something's got to be putting an empty string in there. Finding that may lead you to some other code that would explain the different results.
Without any real code samples, it's hard to troubleshoot.
Perhaps you should try to use HttpRuntime.Cache instead of the HttpContext.Current.Cache.
http://theengineroom.provoke.co.nz/archive/2007/04/27/caching-using-httpruntime-cache.aspx
Difference between HttpRuntime.Cache and HttpContext.Current.Cache?