Improvements to press, click, release for shooting keys - page 3 - General Discussion and Assistance - CHDK Forum supplierdeeply

Improvements to press, click, release for shooting keys

  • 48 Replies
  • 7733 Views
*

Offline lapser

  • *****
  • 1093
Re: Improvements to press, click, release for shooting keys
« Reply #20 on: 28 / December / 2012, 22:46:56 »
Advertisements
This shoot_full_only fix is separate from the shot metering and time lapse stuff. I think it could be added to the trunk soon, without breaking anything.
The key functions should manipulate key state, period. As I explained in my earlier post, I am extremely unlikely to accept a patch that makes them do something else or change their behavior based on shooting state.
The key functions already do more than that. press and release first press or release the key (manipulate the key state), and THEN wait a camera specific delay time. click does both keys, with a delay in between and after.

What are these delays for if not to make the keys do something? All I'm suggesting is to delay based on what's happening in the camera, not just blindly delay. The fixed delay is there to make it more likely that the camera will respond to the button press. Sometimes, a fixed delay just doesn't work, and it wastes time (slows the shot rate).

All I'm doing is changing the fixed delay after pressing shoot_full_only, to a delay until the shutter opens. This allows you to shoot at a little less than 1 shot per second in half_shoot. As Phil discovered, if you set a 1 second interval using shoot_full_only in half_shoot, it misses every other shot. With this change, it would hold shoot_full until the shutter opened, and would shoot at maximum rate, just below 1 shot per second. It would make the current fixed delay after a button press do what it's intended to do. Get the camera to shoot a picture.
Quote
In several posts you have mentioned "the" shoot bug, but I'm not clear what this actually refers to. If you can describe the specific bug you are referring to (or link to previous reports) that would be helpful.
I haven't been able to find the link where I read this. Someone reported a problem where shoot() worked for a few hundred shots, and then hung the camera. Everyone seems to suggest avoiding shoot() for this reason. Can anyone else find what I'm talking about? When I get the time, I'll search some more.
====

I've updated the diff file in the first post, and I think it solves all the problems mentioned here. It's a very simple change, with a big payoff in speeding up shot rate. I think it's ready for trunk 1.2 (I thought it was the unstable, experimental trunk). There appears to be too much resistance here for that to happen.

If someone finds a new problem with the diff, I'll be glad to try to figure out a fix. If anyone who doesn't know how to convert the diff into files for their specific camera would like me to do it for you, post a request with your camera model and firmware version. I'll reply with an attachment for your camera.

Now it's time for me to get back to the timelapse/shot metering & histogram experiments.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 11918
Re: Improvements to press, click, release for shooting keys
« Reply #21 on: 29 / December / 2012, 00:01:04 »
The key functions already do more than that. press and release first press or release the key (manipulate the key state), and THEN wait a camera specific delay time. click does both keys, with a delay in between and after.
I'm not sure the history of the original fixed delay, it has been in the code since revision 243 when the kbd_sched_press/release functions were added. It may be needed for the camera to recognize a button press at all, or it may not be needed at all. In any case, it is entirely deterministic and applies equally every key, no matter what the state of the camera.

This is not true of your change. Your change adds a non-deterministic delay that may vary in camera and setting dependent ways. As I said earlier, movie mode not the only place this matters. Some modes on some cameras will simply refuse to shoot if focus fails. In this case, it appears your shoot_full_only will simply wait indefinitely.

A far more flexible approach would be to give script access to the shutter open time, and let script authors use whatever logic with it they want. You would have to deal with the case of cameras which don't get that value. If the implicit 10ms (+key delays) overhead of action stack actions is too high, that should be addressed. This could address the sleep bug I mentioned earlier too.

Quote
Someone reported a problem where shoot() worked for a few hundred shots, and then hung the camera. Everyone seems to suggest avoiding shoot() for this reason.
This doesn't sound right to me. Shoot is or was broken on some cameras, but my memory is this involved failing to shoot completely (or crashing?), not hanging after many shots. It may be that someone offered using press/release as a misguided alternative, since it is a solution to other cases where shoot fails.

In any case, a bug that is so ill specified and non-reproducible should not be used as an argument for making specific changes.
Don't forget what the H stands for.

*

Offline lapser

  • *****
  • 1093
Re: Improvements to press, click, release for shooting keys
« Reply #22 on: 29 / December / 2012, 01:07:55 »
This is not true of your change. Your change adds a non-deterministic delay that may vary in camera and setting dependent ways. As I said earlier, movie mode not the only place this matters. Some modes on some cameras will simply refuse to shoot if focus fails. In this case, it appears your shoot_full_only will simply wait indefinitely.
Any real problem like that can be solved if it happens. But I doubt that a camera that does that would be very useful for a script trying to shoot as fast as possible with shoot_full_only. Any script will hang if the camera won't shoot.

You've decided not to use this modification, so nothing I say is going to make any difference. I've made my points. It's your decision. Let's move on.
Quote
A far more flexible approach would be to give script access to the shutter open time, and let script authors use whatever logic with it they want. You would have to deal with the case of cameras which don't get that value. If the implicit 10ms (+key delays) overhead of action stack actions is too high, that should be addressed. This could address the sleep bug I mentioned earlier too.
I've already implemented this method in my time lapse routines. It requires 2 new lua functions:
reset_shot_ready()
press("shoot_full_only")
repeat sleep(10) until get_shot_ready()
release("shoot_full_only")

This is what gave me the idea for the shoot_full_only fix. All this can be replaced by:
click("shoot_full_only")

Quote
In any case, a bug that is so ill specified and non-reproducible should not be used as an argument for making specific changes.
Agreed. I saw the potential for shoot() to hang if the camera takes over the keyboard task for a long time. My time lapse experiments suggest that Lua can stop for over a second, possibly related to filling up the SD card with too many pictures. shoot() does the equivalent of click("shoot_full_only") and then waits for the camera to finish taking the picture, which requires that it actually started taking the picture. The click might go by without the camera noticing. My modification holds shoot_full_only until the camera actually starts taking the picture, which eliminates this possibility. Scripts have the same problem with shoot_full_only. The camera often doesn't notice it. My mod fixes both problems.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline lapser

  • *****
  • 1093
Missed Opportunity
« Reply #23 on: 29 / December / 2012, 15:37:48 »
I want to make one last attempt to communicate the importance and benefit of these changes before giving up. Maybe I haven't explained it well enough.

Communication requires more than just a speaker and a listener. To be effective and reliable, the listener must acknowledge that he has received the message from the speaker. This applies to human communication as well as computer communication. So first I will state what I understand you to be saying here.

1. You believe completely that "The key functions should manipulate key state, period." You know this to be absolutely correct, and you will not consider any evidence to the contrary. Thus, no changes to the key functions will ever be implemented, period. Even if I make changes, test them, show that they work, and demonstrate that they significantly improve the function of the camera, you will not read them, you will not test them, you will not implement them, period.

2. Even if these changes work and significantly improve the performance of one camera, there is a possibility that they might not work on other cameras. Even if I eliminate the possibility that they won't work on other cameras in all known ways (video mode, no NR hook), there are still unknown cameras out there that might not work. This would be a catastrophe so severe, that it is not even worth taking the risk of trying even a limited test of these changes. The world might end, and we would all die. Don't even look at the changes or God forbid, try them on your camera, or you could die.

3. Even if my solution solves the shooting problems with a few lines of C code, works faster and reliably, and greatly simplifies writing and learning to write scripts, you will not implement them. There is a way to work around these problems by using multiple ubasic and lua script delay loops that you believe is superior to the proposed changes, and you will not consider evidence to the contrary. The fact that this makes script programming much harder to understand and learn, as well as scripts much harder to get to work is irrelevant to you. You believe that  doing this in a script is superior, period.

Please don't be offending by the satire. I'm just trying to make it as clear as possible how I interpret what you're saying; that is, acknowledge what you have communicated to me, not just what you have said. Here's my response:

1. The key functions are not just a manipulation of the key state. Their fundamental purpose is to communicate with a different thread (task),  so that thread will start a new action.  They are implemented as actions so they can manipulate the key state, and hold that state until the other thread receives it.

The key functions are currently implemented unreliably.  After changing the key state, they wait a fixed amount of time hoping that the other thread will notice the new state.  I call this "delay and pray." This method is fundamentally flawed. Communication with a different thread requires acknowledgement from the other thread that it has received the message.

My modifications are a simple way to get an acknowledgement that the other thread has received the message. I have tested them, and they have worked every time. When my test scripts do click("shoot_full_only"), it works every time, period. You can't argue with success (maybe I should re-examine this belief?) This should also be done with shoot_full, but I removed that part for testing because of your concerns, even though I disagree with you. But you still won't consider testing the code, even on your own camera.

2. The possibility that a change like this won't work on some cameras is real concern. But right now, the key functions don't work reliably on ALL cameras. When a problem occurs, like the phantom "shoot()" bug, it's very difficult to figure out what happened. "Delay and pray" works most of the time. But it introduces subtle bugs that are impossible to reproduce. These are the worst kind.

All of the concerns expressed here involve a bug that hangs the camera every time. These changes should work all the time, or never. These are the best bugs to figure out and fix. CHDK is set up for this purpose, with updates daily to fix bugs. If cameras or scripts show up that don't work, together we can figure out the problem and probably have a fix by the next day. If my changes hang a camera, the user presses the shutter to abort the script. The changes don't effect the camera if a script isn't running. For debugging, if my changes hung the script, I can print the message, "Lapser is an idiot", along with the "Interrupted"message.

3. Using script functions to wait for an acknowledgement from a different thread has real problems. Scripts are not reliable for real time operations. They are slow, and can be interrupted at any time, for several seconds even. The camera could finish the shot and return to its resting state without the script ever noticing. More importantly, it is important to hold the shoot_full or shoot_full_only keys DOWN until receiving the acknowledgement. The only way to do this for the "click" function is to wait for acknowledgement before returning. It can't be done in Lua, so "click" will never work. My changes make "click" work reliably (tested and proven).

CHDK scripts run in the keyboard thread. The keyboard thread also reads the key presses generated by the key functions. The script has to be interrupted repeatedly for the key presses to be recognized. You're also asking the script to monitor the state of the camera to look for an acknowledgement that a key action has been received, but which won't be received unless the script is interrupted often enough. The complexity and inefficiency of this is mind boggling.

What's more, I've implemented this script-based scheme in my time lapse modifications and it doesn't work correctly. The script randomly delays pictures for seconds at a time before it finally recognizes the signal from my C code, and signals back that it's OK to shoot the next picture. If you try to shoot faster than about 2 shots per second, the shots are no longer regular. Attempts at 1 shot per second vary from 1 to 3 seconds between shots.

A few simple modifications to the press, release, and click functions for shoot_full and shoot_full_only would fix all this, yet you refuse to even try it. That's why I labeled this post,

"Missed Opportunity"
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos


*

Offline philmoz

  • *****
  • 3107
    • Photos
Re: Improvements to press, click, release for shooting keys
« Reply #24 on: 29 / December / 2012, 15:42:33 »
Trying to piece together everything from the various threads I've come up with this summary:

  • Your primary goal is to shoot as fast as possible; but be able to measure the exposure of each shot in order to adjust the exposure of the next shot as lighting conditions change.
  • In order to do this you shoot in continuous mode and use press/release shoot_full_only in the script to trigger each shot.
  • Your script needs to know when the raw data from each shot is ready in order to calculate the exposure from the raw buffer and setup the overrides for the next shot.
  • Your script needs to let the raw_savefile code know when it is done with the calculations so it can continue and let the current shot finish processing and saving a JPEG.
  • While trying to do this you have encountered problems with synchronising the script with the image capture code (possibly due to timing, things running in different tasks, or other as yet unidentified bugs).
  • In order to get this to work you have added new state & delay variables to the raw saving process, and are suggesting changing the way the existing press/release/click/shoot function operate.

Naturally there is some reluctance to change the behaviour of existing functionality which will be difficult to test and has the potential to break working code.

So let me throw out an alternative approach to solving your core problem. Note I haven't tested this, and reyalp may have more thoughts on the feasibility of this idea.

It seems to me that the key to your problem is being able to execute some script code at a defined point in the still image capture process - i.e. to recalc exposure when the raw buffer is ready, and ensure the still capture doesn't proceed until you are done.

So why not extend the raw_savefile code to allow it to call a defined function in your script each time a raw image buffer is ready. Lua includes a mechanism for calling script functions from C code (this is used to call the 'restore' function when a script is interrupted).

My suggestion would be to add a new 'shoot_with_callback' function that takes the name of your script function as a parameter and sets up the necessary stuff so raw_savefile calls your function each time.  The return value from the script function could control whether to continue shooting or end the shoot cycle. The new 'shoot_with_callback' would simply loop on the action_stack (with shoot_full pressed) until the script was interrupted or your function returned an exit value.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

*

Offline reyalp

  • ******
  • 11918
Re: Improvements to press, click, release for shooting keys
« Reply #25 on: 29 / December / 2012, 15:54:38 »
So why not extend the raw_savefile code to allow it to call a defined function in your script each time a raw image buffer is ready. Lua includes a mechanism for calling script functions from C code (this is used to call the 'restore' function when a script is interrupted).
This won't work because raw_savefile is run in spytask. Script code has to run from kbd_task, or your lua_State will get trashed. Even if you arrange to call it from kbd task (by setting a flag and checking in kbd_task) it would have to run a a separate lua thread or something. Far better to set a flag that can be monitored in the script.

lapser claims that script is too slow and inefficient, but I don't see actual evidence of this. Even if it is true, the most likely cause is the overhead on action stack items (the fact that processing each item on the action stack takes one kbd_task iteration) which is something that could be solved by allowing kbd_task to process more than one action stack item per iteration in some cases.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 11918
Re: Improvements to press, click, release for shooting keys
« Reply #26 on: 29 / December / 2012, 16:50:20 »
Please don't be offending by the satire. I'm just trying to make it as clear as possible how I interpret what you're saying; that is, acknowledge what you have communicated to me, not just what you have said.
I don't think what you've posted accurately represents the views I've expressed, but since you consider it "satire" it's hard to see the point in responding to it in detail.

I would like to be clear that I'm not rejecting the *functionality* you want to implement, I'm rejecting the implementation. The functionality seems quite useful, and the investigation you've done is certainly worthwhile.
Quote
1. The key functions are not just a manipulation of the key state. Their fundamental purpose is to communicate with a different thread (task),  so that thread will start a new action.
I do fundamentally disagree with this. I believe that the key functions should essentially just approximate a user physically pressing the buttons. This is clear, easily understandable and well defined. It's also the current behavior. If you want to make functions that do something else, then it should be a separate function. shoot() is an example of this.
Quote
The key functions are currently implemented unreliably.
Only if you think they should do something more than approximate a user pressing physical buttons.
Quote
  After changing the key state, they wait a fixed amount of time hoping that the other thread will notice the new state.
This does not accurately reflect what happens. The key state is updated as soon as the kbd_task iteration that processes that action stack item completes. As I said earlier, the reason for the delay on press and release is lost in history. I suspect they are an unnecessary leftover. click does need a hard coded delay, because it is intended to represent a user clicking a button, but that doesn't mean it needs to account for what the camera is doing.
Quote
My modifications are a simple way to get an acknowledgement that the other thread has received the message. I have tested them, and they have worked every time.
The question isn't how many times you've tried, but whether you've thought through all the implications tested all the different scenarios. I have applied patches under the assurance "I've tested this really well, I promise it works" many times, and often regretted it.
Quote
When my test scripts do click("shoot_full_only"), it works every time, period. You can't argue with success (maybe I should re-examine this belief?)
As a maintainer, "working" isn't the the only thing I have to consider. I have to worry about what can be maintained. The CHDK codebase is already almost unmaintainable because people have added lots of things that were useful and working under some limited set of conditions without putting in the effort to get the interfaces right.
Quote
3. Using script functions to wait for an acknowledgement from a different thread has real problems. Scripts are not reliable for real time operations. They are slow, and can be interrupted at any time, for several seconds even.
I don't see evidence of this. If you want, you can fully control when the script yields with set_yield (any preemptive scheduling by the OS would affect C code in kbd_task equally). Lua execution is *not* slow. If you manage yielding yourself, you can run 100000 iterations of a simple loop in a few hundred ms (see http://chdk.setepontos.com/index.php?topic=6729.msg71456#msg71456 but note that's before the introduction of set_yield).
Quote
The camera could finish the shot and return to its resting state without the script ever noticing.
If this is true, then it would apply to any logic in kbd_task.
Quote
More importantly, it is important to hold the shoot_full or shoot_full_only keys DOWN until receiving the acknowledgement. The only way to do this for the "click" function is to wait for acknowledgement before returning. It can't be done in Lua, so "click" will never work. My changes make "click" work reliably (tested and proven).
Only if you assume click is a shooting function, not simply a click of a button. IMO, a script that wants a variable delay should use press and release.
Quote
CHDK scripts run in the keyboard thread. The keyboard thread also reads the key presses generated by the key functions. The script has to be interrupted repeatedly for the key presses to be recognized. You're also asking the script to monitor the state of the camera to look for an acknowledgement that a key action has been received, but which won't be received unless the script is interrupted often enough. The complexity and inefficiency of this is mind boggling.
I don't see why this is "mind boggling". It would follow exactly the same logic as get_shooting
repeat sleep(10) until get_foo()
If the fact that sleep(10) actually requires 3 kbd task iterations is too much, that should be fixed. If that's still to slow, you could make a wait_foo() function.
Quote
What's more, I've implemented this script-based scheme in my time lapse modifications and it doesn't work correctly. The script randomly delays pictures for seconds at a time before it finally recognizes the signal from my C code, and signals back that it's OK to shoot the next picture. If you try to shoot faster than about 2 shots per second, the shots are no longer regular. Attempts at 1 shot per second vary from 1 to 3 seconds between shots.
It seems more likely this is a problem with your implementation than some fundamental limitation of script. Since script can run every iteration of kbd_task, it should be able to do pretty much anything that could be done in kbd_task code.
Don't forget what the H stands for.

*

Offline lapser

  • *****
  • 1093
Re: Improvements to press, click, release for shooting keys
« Reply #27 on: 29 / December / 2012, 17:03:20 »
Thanks for the responses. These proposed changes are completely independent of what I'm doing with the time lapse and exposure routines. That's why I put them in a different thread. I don't need them for my time lapse purposes. I just realized it was possible to get the key functions to work properly when you finally helped me to understand action.stack.c.

But since you brought it up, my shot_interval delay is now at the beginning of capt_seq_hook_set_nr(). The first shot happens immediately, and reaches raw_save_file() about 250 msec after the shutter opens (fast shutter speeds). Right after build_shot_histogram, I increment a variable. The new lua function get_shot_ready checks to see if this variable has changed. Lua polls this variable like this:
repeat sleep(10) until get_shot_ready()

Then Lua reads the now valid exposures from get_shot_meter() and sets the new exposure, using the modified set_tv_direct(tv) that does SET_NOW in half shoot. Then, Lua calls reset_shot_ready() and goes into a loop waiting for get_shot_ready() again.

In continuous mode, shoot_full is held down the whole time, so there are no calls to key functions (why the changes here are not relevant). So the camera is going to start its next shot on its own, independent of Lua. But I also have a delay in capt_seq_hook_set_nr() that waits for reset_shot_ready() (with a 2 second time out). Then, it waits the rest of the interval time, so the interval time is perfect every time, as long as reset_shot_ready happens before the end of the interval.

I save the time from when get_shot_ready() turns true, to when reset_shot_ready() is called by lua. Most of the time this is 0, i.e. less that 10 msec. Every few shots, it can be 1 or 2 seconds, even 3 seconds. This makes the shot rate irregular.

I tried set_yield(-1,-1), figuring that the sleep(x) loop waiting for get_shot_ready() would be enough, but the camera hung up. I can experiment with other values for yield() if you think that would help.

When my lua script crashed once, the camera kept on shooting at 2 shots per second (the time out), but without adjusting exposure. So my current thought is to adjust the exposure before returning from build_shot_histogram() based on lua commands, like set_exposure_compensation(x),  or something. I would skip the wait for reset_shot_ready() in my capt_seq_hook_set_nr() delay routine before the shutter opens. Lua isn't fast enough to set the exposure for each shot, but it could modify the parameters that build_shot_histogram uses without slowing the shot rate.

The idea is to let the camera take shots as fast as it can in continuous mode. Delay each shot in capt_seq_hook_set_nr() if you need a longer interval than the fixed continuous mode shot rate. Eliminate all Lua handshaking, and just have Lua start and stop the process (press, release shoot_full), and change the exposure calculation parameters (not the exposure itself), whenever it wanted to.

Anyway, that's where I'm headed with the time lapse stuff. For single shot mode, I may try pressing shoot_full_only in raw_save_file(), and releasing it in capt_seq_hook_set_nr(). I don't need action stacks for that, just manipulate the key directly, so to speak. That would simulate continuous mode, since Lua would be out of the loop. If you're interested, it might also be a way to add continuous mode to cameras that don't have it, with a CHDK menu option, not a script.

It would be nice to be able to have a call back function capability somehow and eliminate the polling. It might be instructive to figure out how restore() is called at the end of a script. But my problem isn't the speed of recognizing that get_shot_ready() is true, it's getting through the code after that in under 20 or 30 msec max, and not 3 seconds

But anyway, the time lapse/histogram stuff is completely unrelated to the key function proposed changes in this thread. They should be considered on their own.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos


*

Offline lapser

  • *****
  • 1093
Re: Improvements to press, click, release for shooting keys
« Reply #28 on: 29 / December / 2012, 17:43:27 »
Quote
The key functions are currently implemented unreliably.
Only if you think they should do something more than approximate a user pressing physical buttons.
This is the heart of our disagreement. I certainly DO think they should do more than that. A camera user isn't just diddling with physical buttons. He's trying to get the camera to take a picture. How many times have we all lined up in front of a camera, put on our phony smiles, and waited while the photographer diddles with the buttons. When he finally finds the shutter button, he presses it half way, and still no shot. We tell him to press it all the way, which he does, but lets up immediately (before get_shooting()), and STILL no shot. Press it down and HOLD it down for awhile, we yell. He tries that but still lets up too soon. "How long do you have to hold it down?", he asks. "Until you hear the camera take the shot!", you scream. Then he finally takes the shot, and our phony smiles are now irritated grimaces.

Script writers want the same thing. They want to take a picture, not fiddle with buttons. "How long do I hold down the shoot button?" they ask. "Until the camera takes the shot, and you figure out when that happens." you answer.  "Just use click("shoot_full") and I'll make sure you get your shot", I offer.

If you don't see this, there's no point in arguing with you. I'm sympathetic, and extremely grateful for your gatekeeper function. The fact that CHDK works at all is testament to your incredible skills at maintaining code. Without you, there would be no CHDK. You have the final word here, and I don't challenge that.

Is there a way for camera users who don't have the compiler to download a compiled, experimental version of CHDK for their camera that has these changes? I thought that was what the 1.2 branch was for, but if not, is there any other way to do it? Does the philmoz branch get complied for all cameras somewhere? It seems a shame not to at least try it out.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 11918
Re: Improvements to press, click, release for shooting keys
« Reply #29 on: 29 / December / 2012, 17:49:51 »
I tried set_yield(-1,-1), figuring that the sleep(x) loop waiting for get_shot_ready() would be enough, but the camera hung up. I can experiment with other values for yield() if you think that would help.
If you are doing sleep(10) in a loop that's is polling, that is plenty. If there was a crash, it happened for other reasons.

Quote
But my problem isn't the speed of recognizing that get_shot_ready() is true, it's getting through the code after that in under 20 or 30 msec max, and not 3 seconds
If it takes 3 seconds, it's not a problem with raw script execution time unless you are doing something really ridiculous.
Don't forget what the H stands for.

 

Related Topics