Due to a qty value exceeding what a VBScript INT can store, I'm getting a pretty nasty error message (actually the users are)... This is totally a case of twitpocalypse.
Since CINT() will not work in this situation, what is the best workaround?
requestqty = 40200
CInt() max = 32767
CInt(requestqty)
EDIT
CLng() seems to do the trick, any risk to the code to change all CInt() to CLng(). From what I've read below and elsehwere on the web, it seems like there is really very little reason to even use CInt(). I didn't write this particular app and don't know why one was used over the other, but would prefer to not bandaid the issue and completely fix this issue in the app so it does not happen again...
Aways use long instead of int in VBScript (unless you specifically want to limit the value to the int range).
There is no performance benefit for using the smaller type, and there is no storage size benefit because all variables are variants, so all simple types use the same amount of memory.
Use the CLng function instead of the CInt function.
CLng or CDec or CDbl
CLng() and using a Long instead of an Int?
Related
I've run into a strange problem that I've been wrestling with for a few days. I'm hoping someone will have some insights.
I have a Flex app that uses standard remoting to access a SQL db via ColdFusion. (Flex sdk 3.4 (yes, old), CF 10)
I've recently found a problem where if the arguments to a cffunction includes a string that could be a very large number ("2e4361251", for example), the remoting result/fault handler in my AS code will not get called for a VERY long time, effectively locking the app. (App logic requires that I wait for this operation to finish before moving on.)
My most recent test took 45 minutes for the result handler to be called.
What the cffunction does does not matter.
If I am attempting to update my db, the update is successful (whether the string is used in that update or not), my app just doesn't get the result for a very long time;
If the cffunction does NOTHING, like
< cffunction name="myFunc" access="remote">
< !-- do nothing -->
< /cffunction>
it STILL takes an extremely long time to return.
Repeated testing has a noticeable effect on the server; CF starts eating up processor and RAM, though it will eventually recover.
Passing the string IN as a parameter is key; if I'm retrieving the string from the db, there is no problem.
These strings could represent VERY large numbers. If I were trying to do any sort of calculations or other manipulations, I could maybe understand this. But as I said, the function doesn't have to do anything at all, just the presence of the string causes the problem. (And I have verified that it is being passed as a String, not an int, Number, float, decimal, etc)
The string that alerted me to this issue originated with a user. It is a catalogue number of some sort. They had many with different letter/number combos; this one happened to use a single 'E'. I cannot simply 'disallow' strings of this nature.
Anyone have any ideas on why this is happening and, more importantly at the moment, how I can avoid it? A 45 min delay = 'frozen app' to the user.
What is the difference between
void QSqlQuery::clear ()
and
void QSqlQuery::finish ()
Based on the documentation, I don't see what the diff is. What is the difference? I'd like to know specifically when to use one over the other.
EDIT - Some more elaboration and info from documentation.
clear()
-Clears the result set and releases any resources held by the query.
Sounds like finish() does the same...
-Sets the query state to inactive.
Finish does the same.
finish()
-Instruct the database driver that no more data will be fetched from this query until it is re-executed.
What does this mean specifically? What is the consequence of this?
-It may be helpful in order to free resources such as locks or cursors if you intend to re-use the query at a later time.
Doesn't clear do the same? Doesn't clear release locks, cursors, etc?
-Sets the query to inactive.
clear does the same I believe.
-Bound values retain their values.
What is the point of this?
Qt comes with source code, you can see what's the difference by simply looking into the qsqlquery.cpp file
So according to the source code:
clear - clears and resets the QSqlQuery object;
finish - resets the result member of the current query into inactive state;
hope this helps, regards
The language used to describe these functions is similar so it can definitely be a little confusing and I hope this explanation helps. Here's how I interpret and use these methods.
void QSqlQuery::finish ()
I think of this as a way of saying I'm done with the query I just requested (eg no more reading/iterating) but I still plan on using that QSqlQuery object to do more work. You're just releasing any memory/resources used to get the values from the previous query. This really only makes a big, noticeable difference when you're dealing with large datasets over and over again, but I view it as good practice to use none the less.
void QSqlQuery::clear ()
This is my way of saying that I'm done with the QSqlQuery object and want to guarantee that none of the resources/memory I was using gets left around while I'm disposing of the object. I rarely, if ever, use this as I've found that it's effectiveness can vary widely depending on the database you use and if you're using modern C++ features, it doesn't do a lot for you.
It's easier to understand the difference if you look at them as being written to solve a similar problem for two different time periods (eg old C code as opposed to modern C++).
They do very similar things but I'd recommend you just use finish().
For all, like me, that are wondering which method to invoke. I will share my research.
NOTE: I read the sources of the SQLite driver, so other databases drivers can be different.
finish() resets the statement; in SQLite context it calls sqlite3_reset;
clear() resets the whole QSqlQuery object; it clears bound values, prepared statement, lastError(), lastQuery() ..., sets the default options for all object's parameters; in SQLite context I think that sqlite3_finalize is also called;
So I should visualize it like that finish < clear. After finish() you could call exec() to reexecute the query, but after clear() you must prepere the query again and bind its values before you can successfully reexecute the query.
I'm storing phone country codes. They range from 1 to about 300. What's going to be more performant for datatype: int or string? I'm using SQL server 2008 and linq-to-sql.
Thanks.
Note: Whoa, really wierd - you asked about phone codes and I wrote about ZIP codes. Sorry about that! I think the advice still stands though...
Original answer: Performance will most likely be negligible - assign the proper type based on what the data is. ZIP codes, while numeric (in the US at least), aren't numbers - they should be stored as strings.
It is very important to understand the semantic nature of the data you are storing. Once you understand what something is then you can begin to reason about how it should be stored. I am assuming that currently you are storing only the first 5 numbers of a US postal code (like this: 12345).
If you were to store this data as a number this would work. Then imagine that your manager tells you that there is a new requirement that the app you are building will start to collect ZIP codes in the ZIP+4 format (which looks like this: 12345-6789). Now you are stuck with a nasty refactoring that involves either changing the type in the database to varchar(10) or doing some crazy voodoo in your app to strip out the dash when you save the ZIP code and then add it back in for display later.
If you're really worried about space and performance then you could use a smallint (which equates to a int16). This will mean that the data will only take 2 bytes of storage (and 2 bytes in memory).
Given an option where I know the datatype will always be integer, I'll go for integer albeit smaller size - smallint / tinyint (depending on the required range).
I don't expect much difference in performance though.
How are you going to be using them and do any have leading zeros?
If you are going to be combining with phone numbers that are usually stored as string, you want to store them as a string as well or you will waste processing power converting them in every query.
If you aren't planning on doing math or joins with it, it is problably a bad idea to store as a number. Your data set is likely so small and the strings so tiny (300 is the max value) that using an int would probably gain you nothing in a join either.
Country codes are strings (notwithstanding that they use only the characters 0..9) and should be stored as such.
They are so few that you don't need to be concerned about this, though it would be simpler to apply a check constraint with an integer type.
my rule of thumb has always been.. do I need an average? For example, you can store a zip code as integer, but are you ever going to need the average zip code? Probably not. As such, store as char.. unless you may need more than 5 characters, in which case store as varchar.
We are in the process of the optimization of a Flex AS3 Application.
One of my team members suggested we make the variable name lengths smaller to optimize the application performance.
I.e.:
var IsRegionSelected:Boolean = false; //Slower
var IsRS:Boolean = false; //faster
Is this true?
No, the gain you will obtain will be only for the size of the swf.
String are put into a constant pool and instruction refering to this String will use an index.
it can be seen as (very schematic) :
constant pool:
[0] IsRegionSelected
[1] IsRS
usage:
value at 0 = false
value at 1 = false
Your code will be probably translated as (for local variable):
push false
setlocal x
push false
setlocal y
where x and y are register int assign by the compiler, so no difference if it's register 2 or register 4
For more detailed read the avm specification
yep.. i second it. changing the name length is not gonna help you. concentrate on item renderers, effects, states and transitions. those may be killing your resource. also checkout for any embedding images, embedding fonts, etc, since those will increase ur final swf file size and increase initial loading time.
cheers, PK
I don't think so, the way you use your variable name does matter than its length.
Good code should be consistent. Whether that means setting rules for the names of variables and functions, adopting standard approaches, or simply making sure all of your code is indented the same way, consistency makes your code easier for others to read.
One should later construe on what is your variable name declared.
var g:String;
var gang:String;
Both perform the same operation, one is more readability where someone going through your code will also construe it.
There's a very small performance gain, but if you plan to use this application again later, it's not worth your sanity. Do absolutely any other optimization you can before this one - and if it's really slow enough to need optimizing, then there are definitely other factors that you'll need to take care of first before variable names.
Cut anything else you can before resorting to 1-2 millisecond boosts.
As Matchu says, there is a difference but a small one.
You should consider assigning meaningful ids to your variables instead of just using simple chars which have no sense.
I have the feeling that I should not care about thread safe accessing / writing to an
public static int MyVar = 12;
in ASP .NET.
I read/write to this variable from various user threads. Let's suppose this variable will store the numbers of clicks on a certain button/link.
My theory is that no thread can read/write to this variable at the same time. It's just a simple variable of 4 bytes.
I do care about thread safe, but only for refference objects and List instances or other types that take more cycles to read/update.
I am wrong with my presumption ?
EDIT
I understand this depend of my scenario, but wasn't that the point of the question. The question is: it is right that can be written thread safe code with an (static int) variable without using lock keyword ?
It is my problem to write correct code. The answer seems to be: Yes, if you write correct and simple code, and not to much complicated, you can create thread safe functions without the need of lock keyword.
If one thread simply sets the value and another thread reads the value, then a lock is not necessary; the read and write are atomic. But if multiple threads might be updating it and are also reading it to do the update (e.g., increment), then you definitely do need some kind of synchronization. If only one thread is ever going to update it even for an increment, then I would argue that no synchronization is necessary.
Edit (three years later) It might also be desirable to add the volatile keyword to the declaration to ensure that reads of the value always get the latest value (assuming that matters in the application).
The concept of thread 'safety' is too vague to be meaningful unfortunately. If you're asking whether you can read and write to it from multiple threads without the program crashing during the operation, the answer is almost certainly yes. If you're also asking if the variable is guaranteed to either be the old value or the new value without ever storing any broken intermediate values, the answer for this data type is again almost certainly yes.
But if your question is "will my program work correctly if I access this from multiple threads", then the answer depends entirely on what your program is doing. For example, if you run the following pseudo code in 2 threads repeatedly in most programming languages, eventually you'll hit the assertion.
if MyVar >= 1:
MyVar = MyVar - 1
assert MyVar >= 0
Primitives like int are thread-safe in the sense that reads/writes are atomic. But as with most any type, it's left to you to do proper checking with more complex operations. For example, if (x > 0) x--; would be problematic in a multi-threaded scenario because x might change in between the if condition check and decrement.
A simple read or write on a field of 32 bits or less is always atomic. But you should provide your read/write code to make sure that it is thread safe.
Check out this post: http://msdn.microsoft.com/en-us/magazine/cc163929.aspx
It explains why you need to synchronize access to the integers in this scenario
Try Interlocked.Increment() or Interlocked.Add() and you'll be right. Your code complexity will be the same but you truly won't have to worry. If you're not worried about losing a few clicks in your counter, you can continue as you are.
Reading or writing integers is atomic. However, reading and then writing is not atomic. So, if you have one thread that writes and many that read, you may be able to get away without locks.
However, even though the operations are atomic, there are still potential multi-threading issues. In order for one thread to be guaranteed that another thread can see values it writes, you need a memory barrier. Otherwise, the compiler can optimize the code so that the variable stays in a register (or even optimize the operation away completely), so changes would be invisible from one thread to another.
You can establish a memory barrier explicitly (volatile or Thread.MemoryBarrier), or with the Interlocked class -- or with the lock statement (Monitor).