I can't put my finger on why it's doing this, but since a few days help takes a lot of time to show. Either inline (selecting a function, selecting "help for"), or by using the commands doc or help. The command doc cmdname takes about 10 seconds to show the help window. I did, taking fwrite as example, try profile on;doc fwrite;profile viewer and digging through the rabbit hole I arrived on a private java matlab method which is taking forever:
tic;
com.mathworks.mlwidgets.help.HelpUtils.getDocCommandArg('matlab\fwrite', true);
toc
Elapsed time is 9.993832 seconds.
Any idea what could be causing that issue? It also happens in safe mode, with no other running programs than MATLAB. I'd try a complete reinstall of MATLAB, but if I could avoid that that'd be great.
There are a couple of things that might be contributing to this issue, but given the information you've provided it's hard to say exactly what is going on.
When the R2012b help system initializes, it does a few tasks that can sometimes introduce a noticeable delay, mostly related to determining which MathWorks products are available and how you have your help preferences set up. 10 seconds would be unusual, but there is a possibility that this is what's causing the delay. If you're seeing the performance hit on your first use of the help system, but not again in the same MATLAB session, this is the likely cause. This behavior is improved in R2013a.
Other than initialization tasks, the Java call in question is a relatively straightforward search against the same search index that is used for searching the documentation. If you are finding that searching the documentation in the help browser is slow, this would be a hint that the performance issue lies somewhere within the help system's search functionality.
In either case, your best bet is probably to contact MathWorks technical support. It is likely that we can take a closer look at this and possibly come up with some sort of fix.
The problem has been solved with input from mathworks support:
>> tic;doc fwrite;toc
Elapsed time is 20.301202 seconds.
>> tic;reader = org.apache.lucene.index.IndexReader.open(fullfile(docroot,'helpsearch'));
searcher = org.apache.lucene.search.IndexSearcher(reader);
term = org.apache.lucene.index.Term('relpath','ref/plot.html');
query = org.apache.lucene.search.TermQuery(term);
hits = searcher.search(query);
fprintf('Found %d results\n', hits.length); searcher.close; reader.close; toc;
Java exception occurred:
java.io.IOException: Lock obtain timed out:
Lock#C:\Users\b\AppData\Local\Temp\lucene-ca3070c312bc20732565936b371a8bd3- commit.lock
at
org.apache.lucene.store.Lock.obtain(Lock.java:56)
at
org.apache.lucene.store.Lock$With.run(Lock.java:98)
at
org.apache.lucene.index.IndexReader.open(IndexReader.java:141)
at
org.apache.lucene.index.IndexReader.open(IndexReader.java:125)
After that, thinking it was a problem with a temp file being locked, I closed Matlab, went into AppData\Local\Temp\ and cleaned all the temporary files in it.
>> tic;
reader = org.apache.lucene.index.IndexReader.open(fullfile(docroot,'helpsearch'));
searcher = org.apache.lucene.search.IndexSearcher(reader);
term = org.apache.lucene.index.Term('relpath','ref/plot.html');
query = org.apache.lucene.search.TermQuery(term);
hits = searcher.search(query);
fprintf('Found %d results\n', hits.length); searcher.close; reader.close; toc;
Found 5 results
Elapsed time is 0.106868 seconds.
>> tic;doc fwrite;toc
Elapsed time is 0.153808 seconds.
Either it's the cleaning the temp files or the reference to internal java classes org.apache.lucene* that did the trick, but here it is, now doc is fast again.
Related
It has been over a year since I'm using VSCode. Almost every day I search the web for ways to display the time taken (speed) and space taken(during execution) by my program. This info is very important. But unfortunately, I haven't found(or missed) a way to display these metrics. VSCode is cool to use and lightweight etc. etc., but these metrics were visible by default in some other IDEs (like codeblocks). Some extension or some setting I missed in the many articles I went through. If someone could help me out here, I'll be super grateful.
Thank you in advance
if __name__ == "__main__":
'''
Example code shows to display
the Time and Space taking of the program(creating N_gram language model)
'''
import os, psutil, time
start = time.time()
m = create_ngram_model(3, '/content/train_corpus.txt') # Replace withyour custom function
process = psutil.Process(os.getpid())
print('Memory usage in Mega Bytes: ', process.memory_info().rss/(1024**2)) # in bytes
print(f'Time Taken: {time.time() - start}')
You can add this psutil.Process(os.getpid()) at any function(at main thread to see entire memory usage of the program) that you wish to see the status byprocess.memory_info().rss in the running time Memory usage: 0.5774040222167969. Also check this code for to know the program runtime.
I am trying to get familiar with gem5 simulator.
To start, I wrote a simple program with
int main()
{
m5_reset_stats(0, 0);
m5_dump_stats(0, 0);
return 0;
}
I compiled it with util/m5/m5op_x86.S and ran it using...
./build/X86/gem5.opt configs/example/se.py --caches -c ~/tmp/hello
The m5out/stats.txt shows (among other things)...
system.cpu.dcache.ReadReq_hits::total 881
system.cpu.dcache.WriteReq_hits::total 917
system.cpu.dcache.ReadReq_misses::total 54
system.cpu.dcache.WriteReq_misses::total 42
Why is an empty function showing so much hits and misses? Are the hits and misses caused by libc? If so, then what is the purpose of m5_reset_stats() and m5_dump_stats()?
I would check in the stats.txt file if there are two chunks of
---Begin---
---End-----
because as you explained it, the simulator is supposed to dump the stats at dump_stats(0,0) and at the end of the run. So, it seems like you either are looking at one of those intervals (and I would expect the other interval to have 0 for all stats); or there was a bug in the simulation and the dump_stats() (or reset_stats())didn't actually do anything. That actually happened to me plenty of times, but I am not really sure as to the source of this bug.
If you want to troubleshoot further, you could do the following:
Look at the disassembly of your code and find the reset_stats.w and dump_stats.w
Dump a trace from gem5 and see if it ends up executing the dump and reset instructions and also what instructions (and how many) are executed before/after.
Hope this helps!
I'm using EF6 rc1 with Code First strategy, without precompiled views and the problem is:
If I compile and run the exe application it takes like 15 seconds to run the first query (that's okay, since I'm still working on the pre-generated views). But if I use Visual Studio 2013 Preview to Debug the exact same application it takes almost 2 minutes BEFORE running the first query:
Dim Context = New MyEntities()
Dim Query = From I in Context.Itens '' <--- The debug takes 2 minutes in here
Dim Item = Query.FirstOrDefault()
Is there a way to remove this extra time? Am I doing something wrong here?
Ps.: The context itself is not complicated, its just full with 200+ tables.
Edit: Found out that the problem is that during debug time the EF appears to be generating the Views ignoring the pre-generated ones.
Using the source code from EF I discovered that the property:
IQueryProvider IQueryable.Provider
{
get
{
return _provider ?? (_provider = new DbQueryProvider(
GetInternalQueryWithCheck("IQueryable.Provider").InternalContext,
GetInternalQueryWithCheck("IQueryable.Provider").ObjectQueryProvider));
}
}
is where the time is being consumed. But this is strange since it only takes time in debug. Am I missing something here?
Edit: Found more info related to the question:
Using the Process Monitor (by Sysinternals) I found out that there its the 'desenv.exe' process that is consuming tons of time. To be more specific its consuming time with an 'Thread Exit'. It repeats the Thread Exit stack 36 times. I don't know if this info is very useful, but I saved a '.cvs' with the stack, here is his body: [...] (edit: removed the '.cvs' body, I can post it again by the comments if someone really think its going to be useful, but it was confusing and too big.)
Edit: Installed VS2013 Ultimate and Entity Framework 6 RTM. Installed the Entity Framework Power Tools Beta 4 and used it to generate the Views. Nothing changed... If I run the exe it takes 20 seconds, if I 'Start' debugging it takes 120 seconds.
Edit: Created a small project to simulate the error: http://sdrv.ms/16pH9Vm
Just run the project inside the environment and directly through the .exe, click the button and compare the loading time.
This is a known performance issue in Lazy (which EF is using) when the debugger is attached. We are currently working on a fix (the current approach we are looking at is removing the use of Lazy). We hope to ship this fix in a patch release soon. You can track progress of this issue on our CodePlex site - http://entityframework.codeplex.com/workitem/1778.
More details on the coming 6.0.2 patch release that will include a fix are here - http://blogs.msdn.com/b/adonet/archive/2013/10/31/ef6-performance-issues.aspx
I don't know if you have found the solution. But in my case, I had similar issue which wasted me close to a week after trying different suggestions. Finally, I found a solution by changing my web.config to optimizeCompilations="true" and performance improved dramatically from 15-30 seconds to about 2 seconds.
I have four variables, each saved in 365 mat-files (size: 8 x 92 x 240). I try to load these into my function in a for-loop day=1:365, one variable file per day. However, the two first variables always take abnormally long time to load. My code for loading looks like this:
load([eraFolder sprintf('Y%dD%d-tempSD.mat',year,day)], 'tempSD'); % took 5420 s to load
load([eraFolder sprintf('Y%dD%d-tempDewSD.mat',year,day)], 'tempDewSD')
load([eraFolder sprintf('Y%dD%d-eEraSD.mat',year,day)], 'eEraSD'); % took 6 seconds to load
load([eraFolder sprintf('Y%dD%d-pEraSD.mat',year,day)], 'pEraSD');
Using Profiler, I could see that the first two variables took 5420 seconds to load in 365 calls, whereas the the last two variables took 6 and 4 seconds to load respectively over 365 calls. When I swap the order in which variables are loaded, e.g. eEraSD before tempSD, it is still the first two loads that take more time.
When using tic toc to track the time spent on loading, it appears that the time to load a the first or second variable exponentially increases with the number of calls (with the last calls taking 50 seconds to run) . For the third and fourth variable, the loading time stays around 0.02-0.04 seconds per file, more or less independent on how far in the for loop I have gone. See figures below.
When using importdata instead of 'load', the first line takes about 8000 seconds to load 365 times (with the loading exponentially increasing as shown for T in the second figure). The other lines then take about 10 seconds to load 365 times.
I can't understand why it looks this way and what I can do to decrease the loading time. Would greatly appreciate any idea of a possible solution for this.
I suppose your data sets are in the same directory(over network or local) and with same attributes e.g. access properties and so on.
Then the only option left is with the charateristics of the vairbales stored in those matfiles. Can you check how much those variables appear in size e.g. by loading a sample one. This will narrow down to solve your problem.
Hope that help.
FS
Thanks for your help. I finally found out what caused the problem. In a 'for' loop later in the script, I saved other data to a folder I called temp. After renaming that folder to something else (e.g. temporary), the data loading problem disappeared.
(Doesn't matter so much now that the practical problem is solved, but I can't really say I understand why there was this peculiar relationship between the later 'save' call and this 'importdata' or 'load' call.)
Please see new question about the temp folder
My aim is to make a GUI, then by using deploytool to make an exe file from it.
Since I don't want the user to be able to use it for ever I want to make it as a trial version meaning that it will work only for a certain time.
I thought maybe by somehow connecting to the user's computer clock and date, and using the code for a time limit, but I found some problems it this logic.
Any ideas, how it can be done?
Using the computer's clock seems a reasonable way to go. Sure, the user than thwart that by changing the clock, but this will most likely create sufficient inconvenience that they rather pay the reasonable price of the software.
Simply put the following inside the OpeningFcn of your GUI
expiryDate = '2012-12-31';
if now > datenum(expiryDate)
h = errordlg('please upgrade to a full license');
uiwait(h)
return %# or throw an error
end