We had an issue on one of my co workers dev environment earlier this year, I've investigated the issue and found out the problem. The only main difference in his and my machines was that I had not run the windows updates. Since then my pc has forced the updates and now the issue is happening on my machine.
We are both running windows 10 pro, IIS 10.0.17132.1.
The issue. In classic asp, when assigning a value to a class field or reading the value back out of the field, is now taking a lot longer than expected.
Using public or private (with getters / setters) has no affect on the speed.
I've tested the issue on one of our servers and it is not affected with the issue. It is performing pretty similar to how my machine was before.
I've included my test script below. Here are the test results that we are seeing.
server timings. Count: 100000, Assign time: 0.359375, Test time: 0.222656, Other time: 0.527344, Total time: 1.109375, Errors: 0.
local timings. Count: 100000, Assign time: 14.07813, Test time: 13.73438, Other time: 0.460938, Total time: 28.27344, Errors: 0.
<%
dim t, startTime, totalTime, assignTime, testTime, otherTime, n, max, classArray(), data, testVal, errors
class mytest
public myval
end class
startTime = timer
assignTime = 0
testTime = 0
max = 100000
if isEmpty(request("max")) = false and isNumeric(request("max")) = true then max = cLng(request("max"))
if max < 1 then max = 1
errors = 0
redim classArray(max)
for n = 1 to max
set data = new mytest
t = timer
data.myval = "test_" & n
assignTime = assignTime + (timer - t)
set classArray(n) = data
next
for n = 1 to max
set data = classArray(n)
t = timer
testVal = data.myval
testTime = testTime + (timer - t)
if testVal <> "test_" & n then
errors = errors + 1
end if
next
totalTime = (timer - startTime)
otherTime = totalTime - assignTime - testTime
response.write "Count: " & max & ", "
response.write "Assign time: " & round(assignTime, 6) & ", "
response.write "Test time: " & round(testTime, 6) & ", "
response.write "Other time: " & round(otherTime, 6) & ", "
response.write "Total time: " & round(totalTime, 6) & ", "
response.write "Errors: " & errors & "."
%>
From the investigation, I've also seen that it seems to be the call to the class and not actually the applying of the data in the class that's the issue.
Adjusting my class to have two fields and making a function that sets both at the same time (or reads out both as an array). Setting them both manually takes twice as long as the one function call to set both. Reading the data back out has the same affect.
<%
class mytest
public myval
public myval2
public function setdata(v1, v2)
myval = v1
myval2 = v2
end function
public function getdata()
getdata = array(myval, myval2)
end function
end class
set data = new mytest
data.myval = "test"
data.myval2 = "test2"
set data = new mytest
call data.setdata("test", "test2")
%>
I've spent hours searching online for anything related to this, but could not find anything.
So,
has anyone else seen this issue?
is it affecting anyone else's dev environment?
has anyone got any ideas on how to solve this issue?
Thanks @erik
I wanted to upvote you but there seems to be no up-arrow for me next to your comment. But big thanks.
Yes, the version of the vbscript.dll was different on the server. I've replaced those DLL's on my dev environment and my co workers machine and the problem has gone away. We are monitoring logs to see if there is any adverse affects of using the servers DLL's but so far it all looks good.
Had to take ownership of the DLL's from TrustedInstaller before I could replace them but after that it all went smoothly, not sure I had to but I gave ownership back to TrustedInstaller after I was finished.
Both the servers and our dev machines had been windows updated so I assume the DLL differences is platform specific or maybe something in Windows 10 that they wanted to address but not put into the version they pushed to the server when it was updated.
Details.
system32\vbscript.dll
Windows 10 DLL 25/07/2018 17:31 (ver 5.812.10240.16384)
Windows server 2012R2 DLL 19/07/2018 05:33 (ver 5.8.9600.19101)
syswow64\vbscript.dll
Both same date and version as the system32 ones (different file sizes but that's to be expected).