I am playing a bit with Node.js. I've just started writing something new and it stuck me that my simple "console" app takes quite long to respond. This app loads a 5MB json file, turns it into an object but all that still does not take a significant amount of time. My further search (in a quite short and simple code) led me to conclusion that this single line:
this.generated_on = ( new Date() ).toString();
takes around 2.5s to execute. Further investigation made me understand even less. I've modified it to:
this.generated_on = new Date();
this.generated_on = this.generated_on.toString();
(with console.timeLogs in between) and line with toString() was the one that took over 2 seconds to execute. Then, I've modified the code once again:
this.generated_on = new Date('2019-02-04 20:00:00');
this.generated_on = this.generated_on.toString();
and results were other way around. toString() took only 2ms while creating Date object took over 2s.
Why is it so slow? Why so different results? Any faster way to get formatted current time string? (I don't care much about execution time for this project as it works offline, still it bugs me).
I think your development environment is off or something. I cannot tell you why your machine is running the code in a slow manner. I cannot replicate the problem you were saying.
I tried to benchmark the code you have above.
https://repl.it/#act/HotpinkFearfulActiveserverpages
Go here and try clicking on Run button at the top.
Here's the result I am seeing
// Case Togehter:
// this.generated_on = ( new Date() ).toString();
// Case Separately:
// this.generated_on = new Date();
// this.generated_on = this.generated_on.toString();
Together x 332,222 ops/sec ±7.75% (44 runs sampled)
Separtely x 313,162 ops/sec ±8.48% (43 runs sampled)
332,222 ops/sec means an operation took 1/332,222 seconds on average.
I suggest you to use node.js builtin module 'Performance hooks'.
You can find documentation here: https://nodejs.org/dist/latest-v11.x/docs/api/perf_hooks.html#perf_hooks_performance_mark_name
Mark each process from top to bottom and then print the metrics (in milliseconds), you will figure out the actual issue
Related
I'm using pixi-sound.js and want to be able to skip to a specific point in the audio file. I've achieved this before using HTML5 audio by updating the currentTime, but I'm not sure where to access this with pixi-sound. There are at least two currentTime values, as well as 'progress', in the object, but changing those doesn't cause a skip.
var sound = PIXI.sound._sounds['track01'];
var currenttime = sound.media.context.audioContext.currentTime;
I would have thought this would be a common usage thing, but can't find any reference to it in the documents. Any ideas much appreciated.
In PixiJS Sound, you can hand over a options object as an argument for play method of an instance of Sound class. And the value of options.start is the "start time offset in seconds".
References: #pixi/sound v4.2.0 source, pixi-sound v3.0.5 source
In your code, if you want to play the sound from the point of 10 seconds offset, I think you can try like the following:
var sound = PIXI.sound._sounds['track01'];
sound.play({ start: 10 }); // play from 10 seconds offset
I've been using NodeJS running on Firebase hosting to monitor sensor values
(through dedicated hardware). I simply use function setinterval to check
the sensor values via API that I wrote. The system reads from sensor
successfully for every minutes (for just testing) but it stops reading
after 9 minutes (or 540 seconds according to google document here ??). The reading sensor function is working, only the loop in setinterval that stops working as I've mentioned. My simple code looks like this:
var intervalObj = setinterval(function(sensor_id){
var val = readSensorValue(sensor_id);
var d = new Date();
console.log("reading from sensor[" + sensor_id + "] => " + val + "#" + d);
}, 60000);
However, I have to monitor the sensor all day long. How can I fix this??
Or there's any other better approach??
Thank you for your time,
JJ
:D:D:D
I've decided not to use Firebase function hosting for now, so I run the project on the VM and everything's been working fine. Just a simple setInterval... even though I'm still wonder whether it is a design by Firebase for such limitation or there should be other approach for doing this on Firebase.
Thanks for all the comment.
:D:D:D
I'm working on a project which uses nodejs and nighwatch for test automation. The problem here is that the tests are not reliable and give lots of false positives. I did everything to make them stable and still getting the errors. I went through some blogs like https://bocoup.com/blog/a-day-at-the-races and did some code refactoring. Did anyone have some suggestions to solve this issue. At this moment I have two options, either I rewrite the code in Java(removing nodejs and nightwatch from solution as I'm far more comfortable in Java then Javascript. Most of the time, struggle with the non blocking nature of Javascript) or taking snapshots/reviewing app logs/run one test at a time.
Test environment :-
Server -Linux
Display - Framebuffer
Total VM's -9 with selenium nodes running the tests in parallel.
Browser - Chrome
Type of errors which I get is element not found. Most of the time the tests fail as soon the page is loaded. I have already set 80 seconds for timeout so time can't be issue. The tests are running in parallel but on separate VM's so I don't know whether it can be issue or not.
Edit 1: -
Was working on this to know the root cause. I did following things to eliminate random fails: -
a. Added --suiteRetries to retry the failed cases.
b. Went through the error screenshot and DOM source. Everything seems fine.
c. Replaced the browser.pause with explicit waits
Also while debugging I observed one problem, maybe that is the issue which is causing random failures. Here's the code snippet
for (var i = 0; i < apiResponse.data.length; i++) {
var name = apiResponse.data[i];
browser.useXpath().waitForElementVisible(pageObject.getDynamicElement("#topicTextLabel", name.trim()), 5000, false);
browser.useCss().assert.containsText(
pageObject.getDynamicElement("#topicText", i + 1),
name.trim(),
util.format(issueCats.WRONG_DATA)
);
}
I added the xpath check to validate if i'm waiting enough for that text to appear. I observed that visible assertion is getting passed but in next assertion the #topicText is coming as previous value or null.This is an intermittent issue but on test server happens frequently.
There is no magic bullet to brittle UI end to end tests. In the ideal world there would be an option set avoid_random_failures=true that would quickly and easily solve the problem, but for now it's only a dream.
Simple rewriting all tests in Java will not solve the problem, but if you feel better in java, then I would definitely go in that direction.
As you already know from this article Avoiding random failures in Selenium UI tests there are 3 commonly used avoidance techniques for race conditions in UI tests:
using constant sleep
using WebDriver's "implicit wait" parameter
using explicit waits (WebDriverWait + ExpectedConditions + FluentWait)
These techniques are also briefly mentioned on WebDriver: Advanced Usage, you can also read about them here: Tips to Avoid Brittle UI Tests
Methods 1 and 2 are generally not recommended, they have drawbaks, they can work well on simple HTML pages, but they are not 100% realiable on AJAX pages, and they slow down the tests. The best one is #3 - explicit waits.
In order to use technique #3 (explicit waits) You need to familiarize yourself and be comfortable with the following WebDriver tools (I point to theirs java versions, but they have their counterparts in other languages):
WebDriverWait class
ExpectedConditions class
FluentWait - used very rarely, but very usefull in some difficult cases
ExpectedConditions has many predefinied wait states, the most used (in my experience) is ExpectedConditions#elementToBeClickable which waits until an element is visible and enabled such that you can click it.
How to use it - an example: say you open a page with a form which contains several fields to which you want to enter data. Usually it is enought to wait until the first field appears on the page and it will be editable (clickable):
By field1 = By.xpath("//div//input[.......]");
By field2 = By.id("some_id");
By field3 = By.name("some_name");
By buttonOk = By.xpath("//input[ text() = 'OK' ]");
....
....
WebDriwerWait wait = new WebDriverWait( driver, 60 ); // wait max 60 seconds
// wait max 60 seconds until element is visible and enabled such that you can click it
// if you can click it, that means it is editable
wait.until( ExpectedConditions.elementToBeClickable( field1 ) ).sendKeys("some data" );
driver.findElement( field2 ).sendKeys( "other data" );
driver.findElement( field3 ).sendKeys( "name" );
....
wait.until( ExpectedConditions.elementToBeClickable( buttonOK)).click();
The above code waits until field1 becomes editable after the page is loaded and rendered - but no longer, exactly as long as it is neccesarry. If the element will not be visible and editable after 60 seconds, then test will fail with TimeoutException.
Usually it's only necessary to wait for the first field on the page, if it becomes active, then the others also will be.
I'm trying to scrape a webpage with nightmareJS and got stuck.
In my program i pass to the function an array on links which i need to the same data from all of them
The list can be very long (over 60) and if i try to do a
async.each(Links, function (url, callback) {
var nightmare = Nightmare(size);
...
}
Only the first couple few instances actually return a value , others just hang up and wont load (blank page).When i try to do only three it work perfectly.
How can i fix it? How can i redistribute the work , for example three in parallel and only when all done it will do the next set? One more thought maybe use the same instance and repeat the steps for all the links?
There are two possible solutions:
using eachSeries which waits until one operation is done before launching the other one.
Or in async.eachpass another argument which limits how many operation are running in the same time.
I have been very disappointed to find that now that I am ready to migrate my html5 app onto phones using phonegap the ability to play audio is like perpetual motion. It is almost there, but not quite.
The answer for Androids (pre ice cream sandwich at least) is the Phonegap media api. According to everyone.
The problem is that I REALLY care about what the current time is while playing back my audio. On my Mac running Chrome I timed how long it takes to do:
pos=audio.currentTime
and it is less than a millisecond.
With the Phonegap media api I must call an asynchronous function, WAIT till it calls back and then I get the current media position. This takes anywhere from 5 to over 150 milliseconds. It is not consistent and it is distressingly slow.
It also begs the question: what time is it? If it takes 150ms to get the time, did I get the time at the beginning of those 150ms or the end? I really cant be sure that the time I got is really that close to the current time.
Its a good thing I am not still writing submarine navigation software, because with such a horrible source of time I would never be able to determine where I am.
I am now using the system clock to keep track of time, and using getCurrentPosition() to re-sync from time to time. However, I can still be off by over a hundred ms.
My question: Anyone got a better approach?
EDIT:
Looking at the code for Cordova:
/**
* Get current position of playback.
*
* #return position in msec or -1 if not playing
*/
public long getCurrentPosition() {
if ((this.state == STATE.MEDIA_RUNNING) || (this.state == STATE.MEDIA_PAUSED)) {
int curPos = this.player.getCurrentPosition();
this.handler.webView.sendJavascript("cordova.require('cordova/plugin/Media').onStatus('" + this.id + "', " + MEDIA_POSITION + ", " + curPos / 1000.0f + ");");
return curPos;
}
else {
return -1;
}
}
It looks to me like this should execute pretty fast...except for that call to sendJavascript(). I wonder if that is where the mysterious delay is originating?
For my purposes I don't need an onStatus event: I need to get the current position as quickly as I can. So I wonder if I can remove that line of code... I guess that would necessitate a change to the Cordova source itself. :(