[20170909]为什么是12秒.txt

[20170909]为什么是12秒.txt

--//在开发程序时我一般会强调开发尽量不要写一些自定义函数,往往可能导致CPU忙。
--//例子很像这样:

CREATE OR REPLACE FUNCTION get_dept (p_deptno dept.deptno%TYPE)
   RETURN dept.dname%TYPE
IS
   l_dname   dept.dname%TYPE;
BEGIN
   DBMS_LOCK.sleep (1);

   SELECT dname
     INTO l_dname
     FROM dept
    WHERE deptno = p_deptno;

   RETURN l_dname;
END;
/

--//这样定义实际上非常不好,如果执行如下,相当于每行都会调用函数get_dept,形成不必要的递归.
--//本来应该使用表连接解决的,使用函数,有点像标量子查询.
--//当时我建议他好好看一下我写的blog,链接如下:
--// http://blog.itpub.net/267265/viewspace-2138042/ => [20170426]为什么是4秒.txt
--// 结果对方发现在12c for windows下,测试结果与我的测试不符,我重新测试看看.

1.环境:
SCOTT@test01p> @ ver1
PORT_STRING                    VERSION        BANNER                                                                               CON_ID
------------------------------ -------------- -------------------------------------------------------------------------------- ----------
IBMPC/WIN_NT64-9.1.0           12.1.0.1.0     Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0

2.建立函数:
CREATE OR REPLACE FUNCTION get_dept (p_deptno dept.deptno%TYPE)
   RETURN dept.dname%TYPE
IS
   l_dname   dept.dname%TYPE;
BEGIN
   DBMS_LOCK.sleep (1);

   SELECT dname
     INTO l_dname
     FROM dept
    WHERE deptno = p_deptno;

   RETURN l_dname;
END;
/

set timing on
set autot traceonly;

SCOTT@test01p> select empno, ename, deptno, get_dept(deptno) c20 from emp;
14 rows selected.
Elapsed: 00:00:14.02
--//执行多次稳定递归的数量.需要14秒完成.
Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    14 |   182 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| EMP  |    14 |   182 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
         14  recursive calls
          0  db block gets
         36  consistent gets
          0  physical reads
          0  redo size
       1130  bytes sent via SQL*Net to client
        544  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         14  rows processed
--//可以发现递归执行14次(如果不是,执行多次最后会稳定在14次)

--//换成标量子查询:
SCOTT@test01p> select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp;
14 rows selected.
Elapsed: 00:00:12.04
Execution Plan
----------------------------------------------------------
Plan hash value: 1340320406
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    14 |   182 |     9   (0)| 00:00:01 |
|   1 |  FAST DUAL        |      |     1 |       |     2   (0)| 00:00:01 |
|   2 |  TABLE ACCESS FULL| EMP  |    14 |   182 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
         12  recursive calls
          0  db block gets
         32  consistent gets
          0  physical reads
          0  redo size
       1130  bytes sent via SQL*Net to client
        544  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         14  rows processed
--//执行时间是12秒,递归12次.与我在11g下测试不同,11g下测试3秒.

set autot off
alter session set statistics_level=all;

SCOTT@test01p> show array
arraysize 200

SCOTT@test01p> select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp;
...

SCOTT@test01p> @ dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  apagxtf1p2puy, child number 1
-------------------------------------
select empno, ename, deptno, (select get_dept(deptno) from dual )c20
from emp
Plan hash value: 1340320406
--------------------------------------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |       |     9 (100)|          |     14 |00:00:00.01 |       8 |
|   1 |  FAST DUAL        |      |     12 |      1 |       |     2   (0)| 00:00:01 |     12 |00:00:00.01 |       0 |
|   2 |  TABLE ACCESS FULL| EMP  |      1 |     14 |   182 |     3   (0)| 00:00:01 |     14 |00:00:00.01 |       8 |
--------------------------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
   1 - SEL$2 / DUAL@SEL$2
   2 - SEL$1 / EMP@SEL$1
21 rows selected.

--//从执行计划也可以发现fast dual执行了12次.为什么?不好理解?要么3次,要么14次?什么也不应该12次.

3.分析:
--//使用10046跟踪看看
@ 10046on 12
select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp;
@ 10046off

--//检查跟踪文件.
*** 2017-09-09 21:20:16.366
WAIT #181607424: nam='PL/SQL lock timer' ela= 999265 duration=0 p2=0 p3=0 obj#=665 tim=5412716150
=====================
PARSING IN CURSOR #181597968 len=42 dep=1 uid=109 oct=3 lid=109 tim=5412716418 hv=328320763 ad='7ff13e15ba0' sqlid='56r5sd49t3jrv'
SELECT DNAME FROM DEPT WHERE DEPTNO = :B1
END OF STMT
BINDS #181597968:
Bind#0
  oacdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00
  oacflg=03 fl2=1206001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=212a7fb0  bln=22  avl=02  flg=05
  value=20
EXEC #181597968:c=0,e=8900,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=2852011669,tim=5412725274
FETCH #181597968:c=0,e=28,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=1,plh=2852011669,tim=5412725381
STAT #181597968 id=1 cnt=1 pid=0 pos=1 obj=92285 op='TABLE ACCESS BY INDEX ROWID DEPT (cr=2 pr=0 pw=0 time=30 us cost=1 size=13 card=1)'
STAT #181597968 id=2 cnt=1 pid=1 pos=1 obj=92286 op='INDEX UNIQUE SCAN PK_DEPT (cr=1 pr=0 pw=0 time=19 us cost=0 size=0 card=1)'
CLOSE #181597968:c=0,e=3,dep=1,type=3,tim=5412735882
FETCH #181607424:c=0,e=1019217,p=0,cr=7,cu=0,mis=0,r=1,dep=0,og=1,plh=1340320406,tim=5412735943
WAIT #181607424: nam='SQL*Net message from client' ela= 1165 driver id=1413697536 #bytes=1 p3=0 obj#=665 tim=5412737203
...

d:\tools\rlwrap>grep "BINDS #181597968:" D:\app\oracle\diag\rdbms\test\test\trace\test_ora_6436.trc |wc
     12      24     216

--//确实12次.

d:\tools\rlwrap> grep -A5 "BINDS #181597968:" D:\app\oracle\diag\rdbms\test\test\trace\test_ora_6436.trc | grep "^  value="
  value=20
  value=30
  value=20
  value=30
  value=10
  value=20
  value=10
  value=30
  value=20
  value=30
  value=20
  value=10

SCOTT@test01p> select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp;
     EMPNO ENAME          DEPTNO C20
---------- ---------- ---------- --------------------
      7369 SMITH              20 RESEARCH
      7499 ALLEN              30 SALES
      7521 WARD               30 SALES
      7566 JONES              20 RESEARCH
      7654 MARTIN             30 SALES
      7698 BLAKE              30 SALES
      7782 CLARK              10 ACCOUNTING
      7788 SCOTT              20 RESEARCH
      7839 KING               10 ACCOUNTING
      7844 TURNER             30 SALES
      7876 ADAMS              20 RESEARCH
      7900 JAMES              30 SALES
      7902 FORD               20 RESEARCH
      7934 MILLER             10 ACCOUNTING
14 rows selected.

--//对比你可以发现,如果邻近的值一样,函数调用仅仅1次.

SCOTT@test01p> select * from (select empno, ename, deptno, lag(deptno,1) over(order by rownum) next from emp) where deptno=next;
     EMPNO ENAME          DEPTNO       NEXT
---------- ---------- ---------- ----------
      7521 WARD               30         30
      7698 BLAKE              30         30

--//这样减少2次调用,说明12c与11g在标量子查询上处理与原来不同.不知道是什么回事,上班再仔细对比看看(与11g).
--//或者是OS版本的问题....
--//一个简单的验证,建立一个按照deptno排序的表.
create table empx as select * from emp order by deptno;

SCOTT@test01p> select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from empx;
     EMPNO ENAME          DEPTNO C20
---------- ---------- ---------- --------------------
      7782 CLARK              10 ACCOUNTING
      ...
      7654 MARTIN             30 SALES
14 rows selected.
Elapsed: 00:00:03.03

--//现在3秒...如果这样执行:

select t.* ,(select get_dept(t.deptno) from dual ) c20 from ( select empno, ename, deptno  from emp order by deptno) t;
...
Elapsed: 00:00:12.00

--//竟然也是12秒.不过看执行计划马上明白:
SCOTT@test01p> @ dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  248fpg2995yz8, child number 0
-------------------------------------
select t.* ,(select get_dept(t.deptno) from dual ) c20 from ( select
empno, ename, deptno  from emp order by deptno) t
Plan hash value: 3996307794
------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |      1 |        |       |     9 (100)|          |     14 |00:00:12.00 |      31 |       |       |          |
|   1 |  FAST DUAL         |      |     12 |      1 |       |     2   (0)| 00:00:01 |     12 |00:00:00.01 |       0 |       |       |          |
|   2 |  SORT ORDER BY     |      |      1 |     14 |   182 |     9   (0)| 00:00:01 |     14 |00:00:12.00 |      31 |  2048 |  2048 | 2048  (0)|
|   3 |   TABLE ACCESS FULL| EMP  |      1 |     14 |   182 |     3   (0)| 00:00:01 |     14 |00:00:00.01 |       7 |       |       |          |
------------------------------------------------------------------------------------------------------------------------------------------------
--//可以发现 SORT ORDER BY 消耗12秒.也就是在排序前就进行递归调用函数了.
--//对比前面的执行计划,再次发现奇怪问题,看不出前面的执行计划12秒消耗在那里?

--//使用提示MATERIALIZE改写如下:

SCOTT@test01p> with t as ( select /*+MATERIALIZE */ empno, ename, deptno  from emp order by deptno)  select t.*,(select get_dept(t.deptno) from dual ) c20 from t;
     EMPNO ENAME          DEPTNO C20
---------- ---------- ---------- --------------------
      7782 CLARK              10 ACCOUNTING
      7839 KING               10 ACCOUNTING
      ..
      7654 MARTIN             30 SALES
14 rows selected.
Elapsed: 00:00:03.02

SCOTT@test01p> @ dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  fwvgq6403j0nx, child number 0
-------------------------------------
with t as ( select /*+MATERIALIZE */ empno, ename, deptno  from emp
order by deptno)  select t.*,(select get_dept(t.deptno) from dual ) c20
from t
Plan hash value: 2014637640
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                       | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                            |      1 |        |       |    11 (100)|          |     14 |00:00:00.01 |      21 |      1 |      1 |       |       |          |
|   1 |  FAST DUAL                 |                            |      3 |      1 |       |     2   (0)| 00:00:01 |      3 |00:00:00.01 |       0 |      0 |      0 |       |       |          |
|   2 |  TEMP TABLE TRANSFORMATION |                            |      1 |        |       |            |          |     14 |00:00:00.01 |      21 |      1 |      1 |       |       |          |
|   3 |   LOAD AS SELECT           |                            |      1 |        |       |            |          |      0 |00:00:00.01 |      11 |      0 |      1 |  1036K|  1036K|          |
|   4 |    SORT ORDER BY           |                            |      1 |     14 |   182 |     3   (0)| 00:00:01 |     14 |00:00:00.01 |       7 |      0 |      0 |  2048 |  2048 | 2048  (0)|
|   5 |     TABLE ACCESS FULL      | EMP                        |      1 |     14 |   182 |     3   (0)| 00:00:01 |     14 |00:00:00.01 |       7 |      0 |      0 |       |       |          |
|   6 |   VIEW                     |                            |      1 |     14 |   322 |     2   (0)| 00:00:01 |     14 |00:00:00.01 |       7 |      1 |      0 |       |       |          |
|   7 |    TABLE ACCESS FULL       | SYS_TEMP_0FD9D660E_18A8CC5 |      1 |     14 |   182 |     2   (0)| 00:00:01 |     14 |00:00:00.01 |       7 |      1 |      0 |       |       |          |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

4.继续测试使用 DETERMINISTIC Functions:
--//一般如果在在某个函数定义索引,需要DETERMINISTIC,表示返回结果固定。其实即使不固定,也可以这样定义。
CREATE OR REPLACE FUNCTION get_dept (p_deptno dept.deptno%TYPE)
   RETURN dept.dname%TYPE
   DETERMINISTIC
IS
   l_dname   dept.dname%TYPE;
BEGIN
   DBMS_LOCK.sleep (1);

   SELECT dname
     INTO l_dname
     FROM dept
    WHERE deptno = p_deptno;

   RETURN l_dname;
END;
/

SCOTT@test01p> select empno, ename, deptno, get_dept(deptno) c20  from emp;
...
14 rows selected.
Elapsed: 00:00:14.01
--//奇怪! 又回到14秒,而在11g下这样的测试是4秒(注意设置array=200的情况,如果太小,时间会变化).

5.最后补充测试RESULT CACHE的情况:

CREATE OR REPLACE FUNCTION get_dept (p_deptno dept.deptno%TYPE)
   RETURN dept.dname%TYPE
   RESULT_CACHE
IS
   l_dname   dept.dname%TYPE;
BEGIN
   DBMS_LOCK.sleep (1);

   SELECT dname
     INTO l_dname
     FROM dept
    WHERE deptno = p_deptno;

   RETURN l_dname;
END;
/

SCOTT@test01p> select empno, ename, deptno, get_dept(deptno) c20  from emp;
14 rows selected.
Elapsed: 00:00:03.13

SCOTT@test01p> select empno, ename, deptno, get_dept(deptno) c20  from emp;
14 rows selected.
Elapsed: 00:00:00.00

--//第1次执行3秒,第2次执行0秒.修改如下结果一样.
CREATE OR REPLACE FUNCTION get_dept (p_deptno dept.deptno%TYPE)
   RETURN dept.dname%TYPE
   RESULT_CACHE
   DETERMINISTIC
IS
   l_dname   dept.dname%TYPE;
BEGIN
   DBMS_LOCK.sleep (1);

   SELECT dname
     INTO l_dname
     FROM dept
    WHERE deptno = p_deptno;

   RETURN l_dname;
END;
/


总结:
--//不知道是否是OS版本的问题,有机会安装12c在linux下重复测试看看.
--//看来测试环境该转向12c了....那位有12c for linux的版本测试看看...
--//补充测试11g的情况:
SCOTT@book> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@book> GRANT EXECUTE ON SYS.dbms_lock TO SCOTT;
Grant succeeded.

CREATE OR REPLACE FUNCTION get_dept (p_deptno dept.deptno%TYPE)
   RETURN dept.dname%TYPE
IS
   l_dname   dept.dname%TYPE;
BEGIN
   DBMS_LOCK.sleep (1);

   SELECT dname
     INTO l_dname
     FROM dept
    WHERE deptno = p_deptno;

   RETURN l_dname;
END;
/

set timing on
set autot traceonly;
select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp;

SCOTT@book> select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp;
14 rows selected.
Elapsed: 00:00:03.01
Execution Plan
----------------------------------------------------------
Plan hash value: 1340320406
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    14 |   182 |     3   (0)| 00:00:01 |
|   1 |  FAST DUAL        |      |     1 |       |     2   (0)| 00:00:01 |
|   2 |  TABLE ACCESS FULL| EMP  |    14 |   182 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
          3  recursive calls
          0  db block gets
         13  consistent gets
          0  physical reads
          0  redo size
       1114  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         14  rows processed

--//执行多次,基本稳定在3个递归调用.

set autot off
alter session set statistics_level=all;
select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp;

SCOTT@book> @ &r/dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  apagxtf1p2puy, child number 1
-------------------------------------
select empno, ename, deptno, (select get_dept(deptno) from dual )c20 from emp
Plan hash value: 1340320406
--------------------------------------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |       |     3 (100)|          |     14 |00:00:00.01 |       7 |
|   1 |  FAST DUAL        |      |      3 |      1 |       |     2   (0)| 00:00:01 |      3 |00:00:00.01 |       0 |
|   2 |  TABLE ACCESS FULL| EMP  |      1 |     14 |   182 |     3   (0)| 00:00:01 |     14 |00:00:00.01 |       7 |
--------------------------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
   1 - SEL$2 / DUAL@SEL$2
   2 - SEL$1 / EMP@SEL$1
21 rows selected.

--//Id=2.starts=3次,也验证函数调用3次.
--//不知道为什么,也许12.2.0.N版本跟11g一样,没有这个oracle版本等以后再测试吧....

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/267265/viewspace-2144765/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/267265/viewspace-2144765/

内容概要:本文详细阐述了工业母机技术领域中“高级结构设计工程师”这一岗位的全方位任职要求与职业发展路径,涵盖职位对标、目标企业、学历与证书要求、年龄范围、管理半径、晋升关键点、必备工作经验年限以及薪资待遇区间。重点突出该岗位对高端数控机床核心结构(如床身、主轴箱、导轨等)设计能力的要求,强调有限元分析、精度控制、热变形补偿、振动抑制等核心技术能力,并明确指出需具备项目主导经验、团队管理能力和跨部门协作经验。同时,根据不同企业类型和发展阶段,给出了清晰的年薪划分标准,体现了市场对该岗位的技术深度与综合能力的高度认可。; 适合人群:具备5年以上工业母机或高端机床结构设计经验,致力于向高级工程师、技术专家或管理岗位发展的结构设计从业者;或希望转型进入高端装备制造业的精密机械研发人员。; 使用场景及目标:①用于求职者精准定位职业发展方向,评估自身与高级岗位之间的能力差距;②辅助企业制定人才招聘标准与薪酬体系;③指导技术人员规划技能提升路径,聚焦核心技术积累与项目经验沉淀。; 阅读建议:建议结合个人职业发展阶段对照文中各项指标进行自我诊断,重点关注“晋升关键点”与“必备年限”部分,有针对性地补齐技术短板、积累主导项目经验,并注重专利成果与团队管理能力的培养,以全面提升竞争力。
源码下载地址: https://pan.quark.cn/s/a92ed831069e ### Jmeter工具对验证码的处理方法 #### 一、引言 随着互联网应用安全性的不断提升,验证码已成为网站登录流程中的关键环节。然而,对于性能测试工程师而言,如何高效利用JMeter工具处理登录过程中的验证码构成了一项挑战。本文将系统性地阐述在JMeter中配置和处理验证码的方法,旨在帮助读者熟练掌握这一技能。 #### 二、JMeter中处理验证码的方法与步骤 ##### 1. 创建线程组 在JMeter中构建一个线程组,该线程组将作为执行测试的起始点。在此线程组内,需要添加各类采样器、监听器及其他必要组件,以模拟用户的登录行为。 ##### 2. 新建获取验证码的HTTP请求 在已创建的线程组中,添加一个HTTP请求采样器来模拟用户获取验证码的操作。特别需要注意的是,若目标网站的验证码以图片形式呈现,必须配置正确的HTTP请求以获取该图片。 ##### 3. 配置后置处理器解析验证码 由于通过HTTP请求无法直接获取验证码的值,因此需要增设一个后置处理器实现这一功能。推荐采用BeanShell Post Processor,这是一种高度灵活的脚本编写方式,能够充分满足解析验证码的需求。具体的代码实现可参考以下链接:[http://blog.csdn.net/xreztento/article/details/48682923](http://blog.csdn.net/xreztento/article/details/48682923)。 在BeanShell Post Processor中,需编写一段代码来解析获取到的验证码图片,并将其保存至JMeter的用户自...
内容概要:本文聚焦于扩散模型在光伏场景生成中的应用,深入研究了去噪概率扩散模型(DDPM)的理论基础与Python代码实现。通过构建简化的DDPM模型,实现对光伏功率时序数据的高波动性场景生成,有效模拟新能源出力的不确定性。文章系统阐述了前向扩散过程与逆向去噪过程的数学原理、神经网络架构设计及训练策略,并提供完整的代码实践指导,适用于新能源电力系统规划、不确定性建模与风险评估等任务。同时,文档整合了生成对抗网络(GAN)、条件生成模型、联邦学习、优化算法等相关技术资源,形成支撑科研复现与创新的完整技术体系。; 适合人群:具备Python编程基础和机器学习基础知识,从事新能源、电力系统、人工智能等相关领域研究的研发人员及高校研究生。; 使用场景及目标:①掌握DDPM在光伏功率时序数据生成中的建模方法与实现流程;②深入理解扩散模型相较于传统GAN在生成质量、训练稳定性与时序建模方面的优势;③为电力系统不确定性分析、储能优化配置、调度决策等提供高质量、多样化的输入场景;④结合文档提供的其他代码资源,开展多模型对比研究与综合性科研项目复现与拓展。; 阅读建议:此资源以代码实现为核心,强调理论推导与工程实践的深度融合,建议读者在学习过程中同步运行并调试代码,细致理解每一模块的设计意图与数学依据,并积极参考文档中列出的相关研究方向进行延伸探索与创新应用。
代码转载自:https://pan.quark.cn/s/a4b39357ea24 KeymouseGo 简体中文 | English 功能:记录用户的鼠标键盘操作,通过触发按钮自动执行之前记录的操作,可设定执行的次数,可以理解为 的 。 用途:在进行某些操作简单、单调重复的工作时,使用本软件就可以很省力了。 自己只要做一遍,然后接下来就让电脑来做。 目录 安装 使用方法 + 基本操作 + 提示 + 脚本语法说明 关于作者 开源贡献者 安装 该软件通过 语言编写,已打包为可执行文件,未安装 的用户可直接下载 release 版本 ,直接点击 运行 源码打包可执行文件 打包完成后,可执行文件在项目路径的文件夹内。 使用方法 基本操作 桌面模式 1、点击 按钮,开始录制。 2、在计算机上进行任意操作,如点击鼠标、键盘输入,这部分的动作会被记录下来。 3、点击 按钮,结束录制。 4、点击 按钮,计算机会重复执行一遍第2步中所录制的动作。 命令行模式 直接运行指定脚本: 运行指定脚本3次: 提示 1、可设置脚本重复执行的次数,如果为 即为无限循环。 2、默认启动热键为 ,功能等同于 按钮;默认终止热键为 ,按下后将会停止正在运行的脚本。 3、录制时只记录鼠标点击动作和键盘动作,不记录鼠标移动轨迹。 4、每次录制结束后都会在 目前下生成一个新的脚本文件。 5、运行前可以在列表中选择一个需要执行的脚本。 6、 下的脚本文件内容可以修改,修改时可参考如下所述 。 7、热键设置中的指代鼠标中键,指代鼠标侧键 8、由于程序速度受限,当输入的鼠标速度大于一定值时脚本将无法以预期的输入速度执行 9、部分系统环境中,可能出现无法录制完整的鼠标事件的情况,请以管理员身份/root身份运行...
内容概要:本文围绕“考虑隐私保护的分布式联邦学习电力负荷预测研究”展开,提出了一种融合联邦学习框架与隐私保护机制的电力负荷预测方法,旨在解决传统集中式数据处理中潜在的用户隐私泄露问题。通过构建分布式模型训练体系,各参与方在本地完成模型训练,仅向中心服务器上传模型参数或梯度信息,实现“数据不动模型动”的协同建模模式,确保数据“可用不可见”。研究采用Python语言实现了完整的联邦学习流程,涵盖客户端本地训练、全局模型聚合、隐私保护策略(如差分隐私或同态加密)集成、通信机制设计及预测性能评估等核心模块,显著提升了电力负荷预测在隐私安全与模型精度之间的平衡能力。; 适合人群:具备Python编程基础和机器学习基础知识,从事电力系统、智能电网、能源大数据分析、数据隐私保护等相关领域研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①应用于居民或工业级电力负荷预测任务,在保障用户用电数据隐私的前提下实现高精度预测;②为构建符合数据合规要求的智慧能源管理系统提供技术支撑;③推动联邦学习在能源互联网、跨企业数据协作等场景中的落地应用,促进多方协同建模与数据价值释放。; 阅读建议:建议读者结合文中提供的Python代码进行实践操作,重点关注联邦学习的通信轮次设置、本地训练迭代策略、模型聚合算法设计以及隐私噪声添加机制的实现细节,并可根据实际需求替换底层预测模型(如LSTM、XGBoost、Transformer等)以进一步优化预测性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值