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.
Related
i know this forum dislikes "open" questions like this, nevertheless i'd like somebody to help untie the knot in my head, much appreciated.
The goal is simple:
read a stereo 32bit 44100 S/s I2S signal from 2 adafruit sph0645 mics
create a wav-header and store the data onto an SD-card
I've been at this for a few days now and i know that this will be much more complicated than i originally thought. Main reason: signal quality. Like most tutorials on this subject the simplest "hello world" for these mics is a looped polling for I2S-samples. Poll, fill buffer, output via serial or write to SD-card. This returns a choppy, noisy, sped up version of RL-audio. The filling of the internal DMA-buffers can be seen as constant, but the rest is mostly chaos, so
how to i sync these DMA-buffers with the rest of my code?
From experience with the STM32 HAL i'd imagine some register which can be set to throw an interrupt whenever a buffer is full, or an event which can be sent between tasks via queues. Examples on this subject either poll in a main loop with mono an abysmal sample-rate and bit depth or use pages of overkill code and never adress what it does, "just copy and it works", not good. Does the ESP32-Arduino framework provide some way to to this properly? The espressif-documentation isn't something to look forward to, since some of their I2S interface functions don't even work (if you are researching this topic as well, you too might have noticed that i2s_read only returns zeros). Just a hint into the right direction would help, i'm writing my own code anyway. Interrupts? Events? Timers? Polling for full buffers? Only you might know.
have a good one, thx
Thanks to https://github.com/atomic14/ i now have an answer for a syncing-method which works very well. This method has been tried by https://esp32.com/viewtopic.php?t=12546 who also didn't fully understand what was going on: the espressif i2s-interface offers a flag stored in an event which is triggererd every time one of the specified dma-buffers has received a full set of data, ergo, is full. It looks like this:
while(<your condition>){
i2s_event_t evt;
if (xQueueReceive(<your queue>, &evt, portMAX_DELAY) == pdPASS){
if (evt.type == I2S_EVENT_RX_DONE){
size_t bytesRead = 0;
do{
//read data via i2s_read or i2s_read_bytes
} while (bytesRead > 0);
No data is stored in this queue, but rather a flag which can then be used to synchronize dma-filling and further buffering/calculating/sending the read data.
HOWEVER this only works if you install the i2s driver in a specific setup. Instead of using
i2s_driver_install(I2S_NUM_0, &i2s_config, 0, NULL);
in your setup, you can activate the "affinity" for events by passing a queue-handle and a lenght:
i2s_driver_install(I2S_NUM_0, &i2s_config, 4, &<your queue>);
hope this helps getting started, it sure did help me.
i'm using this on push button click in Qt:
QString fileName = QFileDialog::getSaveFileName(this, tr("Save file"),
QString(),
tr("(*.csv));
it take 3-4 second to open the save Form. why? how i can improve speed?
Try to connect this slot to a QPushButton:
void MainWindow::openFD(){
QTime myopentime=QTime::currentTime();
for (int i=0;i<1000000;i++) ;//comment out this line for the real test
QString fileName = QFileDialog::getSaveFileName(this,QString(),QString(myopentime.toString("m.s.zzz")+" "+QTime::currentTime().toString("m.s.zzz"))
,tr("*.csv") );
}
Then try to run it with and without the count part.
You will see, that the count part adds some ms... without it there is not even ms (mili-second) of difference in the time shown in filename place.
So, you have to search somewhere else in your code or give us a better example.
PS:
1) You will need :
#include <QTime>
2) The line that counting is there to show you that my method works (since you will see some difference when uncomment)
Result and Answer: The problem is not on QFileDialog if this test will not give you differences but somewhere else in your code or possibly in the Window manager of your OS.
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 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.
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