Java classloading выполнение чрезвычайно медленного?
Лемматизатор WordNet действительно учитывает POS-тег, но не определяет его магическим образом:
>>> nltk.stem.WordNetLemmatizer().lemmatize('loving')
'loving'
>>> nltk.stem.WordNetLemmatizer().lemmatize('loving', 'v')
u'love'
Без POS-тега он предполагает, что все, что вы кормите, является существительное. Так что здесь он думает, что вы передаете ему существительное «любящий» (как в «сладкой любви»).
6 ответов
At 30 seconds, you should be able to "profile" your code and see exactly where the problem lies (in loading of the class? in creating the instance? in looking up the method? etc?)
Since it's taking 30 seconds (and not something much smaller, on the order of 10ms or so), you can just use System.out.println(new Date()); between each line of your code.
I suspect you'll find it's the loader.loadClass(String) taking so long - and I suspect that you'll find you either have a very long classpath, or a classpath that includes a network resource of some sort.
Check your default classpath. Maybe it refers to an unavailable network share or something like that.
It's possible that when you create the instance it causes many other classes to load, some of which have static initializers that do stuff that takes a long time. Put this code in a loop and see what subsequent object creations cost.
Edit: Cool, based on your profiling this sounds like you're getting close to the root cause. Another thing to consider is if you are using libraries that have big startup costs. I use iBatis to manage our interactions with Oracle, and when it first fires up it reads in a bunch of XML files and processes the query patterns in them. There's a noticable lag. It'd be interesting to hear what you find out, but you might decide the one time cost is tolerable.
There's nothing wrong with your code... I was able to compile your program in less than a second. I'm running java 1.6.11 on Vista Business.
Perhaps your public string doit(string arg) method is what's taking so long. Can you try invoking it without using reflection to see if it takes a long time? Try having doit() simply return the parameter you pass in (rather than reverse the characters) to see if your reversal algorithm is what's slowing it down.
Is it possible for you to put Foo in the default CLASSPATH so you can just use something like:
ClassLoaderTest.class.getClassLoader()
, where ClassLoaderTest is the class you're running in. Or, provided if you're not running in a static context, then:
this.getClass().getClassLoader()`
Either of these will save you instantiating a new class loader.
But I don't know if this will even help you (you have to profile), and reflection is always going to be noticeably slower. There's no getting around that. Of course, it should be used minimally in production, for this and other reasons.
EDIT: Since loadClass is taking most of the time, it could be that C:\jtest is cluttered. You can try putting Foo.class alone in a directory and using that as the URL. Of course, the reason it is faster the second time is that Foo is already loaded.
Для справки: Возможно, для вас это немного поздно, но я наткнулся на ту же проблему и нашел этот пост.
Похоже, // заставляет удаленный поиск, если вы запустите с -verbose: class, будет загружено исключение UnknownHostException, поэтому оно должно будет выброшено внутри во время загрузки класса.
Я пробовал следующее:
URL url = новый URL ("file: // localhost / C: / jtest /");
и это работает (почти) так же быстро в качестве решения с одинарной косой чертой.