CommandHelper Builds

Be aware that this branch (instanceof-broken) is not the main branch (master)!


Go to main branch View stable downloads

View last successful build

Branch # Status Changes Finished
instanceof-broken #3618- Tests passed: 649, ignored: 12
  • Add better logging when the NoClassDefError is thrown (8daf8b by ladycailin)
1 week ago
instanceof-broken #3617- Tests passed: 649, ignored: 12
  • Probable fix for slowness. This commit caches the native class along with the FQCN, which can be used to seriously speed up the lookup elsewhere, particularly when using instanceof. The only exception to this is DynamicEnums, but there are so few of those that it doesn't cause enough of a performance hit. This speeds up RandomTests by an order of magnitude, but there were other performance increases that should have helped some as well (though not an order of magnitude.) The end result is that this should actually be a bit faster than the original code anyways. (3e2899 by ladycailin)
1 week ago
instanceof-broken #3613- Tests passed: 649, ignored: 12; exit code 1
  • Add minor optimization to CClassType If both compared classes are native, and one extends the other, we can reliably say it is an instanceof, so just use the native java instanceof mechanism. This only helps a tiny bit, but it does help, so this will stay, even though this is not the correct solution. (92e71a by ladycailin)
  • Add some caches to speed things up in the course of operation (4fce2a by ladycailin)
1 week ago
instanceof-broken #3612- Tests passed: 649, ignored: 12; exit code 1 (new)
  • Use isInstanceOf everywhere. This changes the code everwhere to use .isInstanceof instead of instanceof, since this is needed for user objects to work. However, the code is *incredibly* slow, so much so that RandomTests takes 60 seconds on my computer. I added some caches, but that didn't really work well enough either. So the next thought is to add this to the jarInfo perhaps, but even still, once user classes are added,that will increase startup time even more, so I think this has to be solved in a more general way. I think the next step is to very closely examine the code path of isInstanceOf, and see what steps are there today, and figure up if any can be removed, replaced with more efficient mechanisms, or at least further cached. This will serve as the basis of the continued work on objects, but until this is fixed, it utterly kills the runtime performance, and simply cannot be merged in to master. (0865c2 by ladycailin)
1 week ago

Available as:  RSS feed JSON feed