1.TiDB 源码阅读系列文章(五)TiDB SQL Parser 的源码阅读实现
2.Django的懒加载是什么(2023年最新解答)
3.Go语言源码阅读分析(3)-- unsafe
4.vn.py学习笔记(八)vn.py utility、BarGenerator、计划ArrayManager源码阅读
5.Tornado之ioloop源码学习
TiDB 源码阅读系列文章(五)TiDB SQL Parser 的源码阅读实现
本文是 TiDB 源码阅读系列文章的第五篇,主要内容围绕 SQL Parser 功能实现进行讲解。计划内容源自社区伙伴马震(GitHub ID:mz)的源码阅读投稿。系列文章的计划非凡艺术源码目的是与数据库研究者及爱好者深入交流,收到了社区的源码阅读积极反馈。后续,计划期待更多伙伴加入 TiDB 的源码阅读探讨与分享。
TiDB 的计划源码阅读系列文章,帮助读者系统性地学习 TiDB 内部实现。源码阅读最近的计划《SQL 的一生》一文,全面阐述了 SQL 语句处理流程,源码阅读从接收网络数据、计划MySQL 协议解析、源码阅读SQL 语法解析、查询计划制定与优化、执行直至返回结果。
其中,SQL Parser 的功能是将 SQL 语句按照 SQL 语法规则进行解析,将文本转换为抽象语法树(AST)。此功能需要一定背景知识,下文将尝试介绍相关知识,以帮助理解这部分代码。
TiDB 使用 goyacc 根据预定义的 SQL 语法规则文件 parser.y 生成 SQL 语法解析器。这一过程可在 TiDB 的 Makefile 文件中看到,通过构建 goyacc 工具,使用 goyacc 依据 parser.y 生成解析器 parser.go。
goyacc 是 yacc 的 Golang 版本,因此理解语法规则定义文件 parser.y 及解析器工作原理之前,需要对 Lex & Yacc 有所了解。Lex & Yacc 是用于生成词法分析器和语法分析器的工具,它们简化了编译器的编写。
下文将详细介绍 Lex & Yacc 的工作流程,以及生成解析器的过程。我们将从 Lex 根据用户定义的 patterns 生成词法分析器,词法分析器读取源代码并转换为 tokens 输出,以及 Yacc 根据用户定义的语法规则生成语法分析器等角度进行阐述。
生成词法分析器和语法分析器的过程,用户需为 Lex 提供 patterns 的定义,为 Yacc 提供语法规则文件。这两种配置都是文本文件,结构相同,分为三个部分。我们将关注中间规则定义部分,并通过一个简单的例子来解释。
Lex 的涨跌家数折线图源码输入文件中,规则定义部分使用正则表达式定义了变量、整数和操作符等 token 类型。例如整数 token 的定义,当输入字符串匹配正则表达式时,大括号内的动作会被执行,将整数值存储在变量yylval 中,并返回 token 类型 INTEGER 给 Yacc。
而 Yacc 的语法规则定义文件中,第一部分定义了 token 类型和运算符的结合性。四种运算符都是左结合,同一行的运算符优先级相同,不同行的运算符,后定义的行具有更高的优先级。语法规则使用 BNF 表达,大部分现代编程语言都可以使用 BNF 表示。
表达式解析是生成表达式的逆向操作,需要将语法树归约到一个非终结符。Yacc 生成的语法分析器使用自底向上的归约方式进行语法解析,同时使用堆栈保存中间状态。通过一个表达式 x + y * z 的解析过程,我们可以理解这一过程。
在这一过程中,读取的 token 压入堆栈,当发现堆栈中的内容匹配了某个产生式的右侧,则将匹配的项从堆栈中弹出,将该产生式左侧的非终结符压入堆栈。这个过程持续进行,直到读取完所有的 tokens,并且只有启始非终结符保留在堆栈中。
产生式右侧的大括号中定义了该规则关联的动作,例如将三项从堆栈中弹出,两个表达式相加,结果再压回堆栈顶。这里可以使用 $position 的形式访问堆栈中的项,$1 引用第一项,$2 引用第二项,以此类推。$$ 代表归约操作执行后的堆栈顶。本例的动作是将三项从堆栈中弹出,两个表达式相加,结果再压回堆栈顶。
在上述例子中,动作不仅完成了语法解析,还完成了表达式求值。一般希望语法解析的结果是一颗抽象语法树(AST),可以定义语法规则关联的银龙指标源码通达信动作。这样,解析完成时,我们就能得到由 nodeType 构成的抽象语法树,对这个语法树进行遍历访问,可以生成机器代码或解释执行。
至此,我们对 Lex & Yacc 的原理有了大致了解,虽然还有许多细节,如如何消除语法的歧义,但这些概念对于理解 TiDB 的代码已经足够。
下一部分,我们介绍 TiDB SQL Parser 的实现。有了前面的背景知识,对 TiDB 的 SQL Parser 模块的理解会更易上手。TiDB 使用手写的词法解析器(出于性能考虑),语法解析采用 goyacc。我们先来看 SQL 语法规则文件 parser.y,这是生成 SQL 语法解析器的基础。
parser.y 文件包含 多行代码,初看可能令人感到复杂,但该文件仍然遵循我们之前介绍的结构。我们只需要关注第一部分 definitions 和第二部分 rules。
第一部分定义了 token 类型、优先级、结合性等。注意 union 结构体,它定义了在语法解析过程中被压入堆栈的项的属性和类型。压入堆栈的项可能是终结符,也就是 token,它的类型可以是 item 或 ident;也可能是非终结符,即产生式的左侧,它的类型可以是 expr、statement、item 或 ident。
goyacc 根据这个 union 在解析器中生成对应的 struct。在语法解析过程中,非终结符会被构造成抽象语法树(AST)的节点 ast.ExprNode 或 ast.StmtNode。抽象语法树相关的数据结构定义在 ast 包中,它们大都实现了 ast.Node 接口。
ast.Node 接口有一个 Accept 方法,接受 Visitor 参数,后续对 AST 的处理主要依赖这个 Accept 方法,以 Visitor 模式遍历所有的节点以及对 AST 做结构转换。例如 plan.preprocess 是对 AST 做预处理,包括合法性检查以及名字绑定。
union 后面是小鹿源码站是不是真的对 token 和非终结符按照类型分别定义。第一部分的最后是对优先级和结合性的定义。文件的第二部分是 SQL 语法的产生式和每个规则对应的 aciton。SQL 语法非常复杂,大部分内容都是产生式的定义。例如 SELECT 语法的定义,我们可以在 parser.y 中找到 SELECT 语句的产生式。
完成语法规则文件 parser.y 的定义后,使用 goyacc 生成语法解析器。TiDB 对 lexer 和 parser.go 进行封装,对外提供 parser.yy_parser 进行 SQL 语句的解析。
最后,我们通过一个简单的例子,使用 TiDB 的 SQL Parser 进行 SQL 语法解析,构建出抽象语法树,并通过 visitor 遍历 AST。我实现的 visitor 只输出节点的类型,运行结果依次输出遍历过程中遇到的节点类型。
了解 TiDB SQL Parser 的实现后,我们有可能实现当前不支持的语法,如添加内置函数。这为我们学习查询计划以及优化打下了基础。希望这篇文章对读者有所帮助。
作者介绍:马震,金蝶天燕架构师,负责中间件、大数据平台的研发,今年转向 NewSQL 领域,关注 OLTP/AP 融合,目前在推动金蝶下一代 ERP 引入 TiDB 作为数据库存储服务。
Django的懒加载是什么(年最新解答)
导读:本篇文章首席CTO笔记来给大家介绍有关Django的懒加载是什么的相关内容,希望对大家有所帮助,一起来看看吧。Django源码阅读(一)项目的生成与启动诚实的说,直到目前为止,我并不欣赏django。在我的认知它并不是多么精巧的设计。只是由功能堆积起来的"成熟方案"。但每一样东西的崛起都是时代的选择。无论你多么不喜欢,但它被需要。希望有一天,python能有更多更丰富的成熟方案,且不再被诟病性能和可维护性。(屁话结束)
取其精华去其糟粕,django的优点是方便,我们这次源码阅读的水果蔬菜百货网站源码目的是探究其方便的本质。计划上本次源码阅读不会精细到每一处,而是大体以功能为单位进行解读。
django-adminstartprojectHelloWorld即可生成django项目,命令行是exe格式的。
manage.py把参数交给命令行解析。
execute_from_command_line()通过命令行参数,创建一个管理类。然后运行他的execute()。
如果设置了reload,将会在启动前先check_errors。
check_errors()是个闭包,所以上文结尾是(django.setup)()。
直接看最后一句settings.INSTALLED_APPS。从settings中抓取app
注意,这个settings还不是我们项目中的settings.py。而是一个对象,位于django\conf\__init__.py
这是个Settings类的懒加载封装类,直到__getattr__取值时才开始初始化。然后从Settings类的实例中取值。且会讲该值赋值到自己的__dict__上(下次会直接在自己身上找到,因为__getattr__优先级较低)
为了方便debug,我们直接写个run.py。不用命令行的方式。
项目下建个run.py,模拟runserver命令
debug抓一下setting_module
回到setup()中的最后一句apps.populate(settings.INSTALLED_APPS)
开始看apps.populate()
首先看这段
这些App最后都会封装成为AppConfig。且会装载到self.app_configs字典中
随后,分别调用每个appConfig的import_models()和ready()方法。
App的装载部分大体如此
为了方便debug我们改写下最后一句
res的类型是Commanddjango.contrib.staticfiles.management.commands.runserver.Commandobjectat0xEDA0
重点是第二句,让我们跳到run_from_argv()方法,这里对参数进行了若干处理。
用pycharm点这里的handle会进入基类的方法,无法得到正确的走向。实际上子类Commond重写了这个方法。
这里分为两种情况,如果是reload重载时,会直接执行inner_run(),而项目启动需要先执行其他逻辑。
django项目启动时,实际上会启动两次,如果我们在项目入口(manage.py)中设置个print,会发现它会打印两次。
第一次启动时,DJANGO_AUTORELOAD_ENV为None,无法进入启动逻辑。会进入restart_with_reloader()。
在这里会将DJANGO_AUTORELOAD_ENV置为True,随后重启。
第二次时,可以进入启动逻辑了。
这里创建了一个django主线程,将inner_run()传入。
随后本线程通过reloader.run(django_main_thread),创建一个轮询守护进程。
我们接下来看django的主线程inner_run()。
当我们看到wsgi时,django负责的启动逻辑,就此结束了。接下来的工作交由wsgi服务器了
这相当于我们之前在fastapi中说到的,将fastapi的app交由asgi服务器。(asgi也是django提出来的,两者本质同源)
那么这个wsgi是从哪来的?让我们来稍微回溯下
这个settings是一个对象,在之前的操作中已经从settings.py配置文件中获得了自身的属性。所以我们只需要去settings.py配置文件中寻找。
我们来寻找这个get_wsgi_application()。
它会再次调用setup(),重要的是,返回一个WSGIHandler类的实例。
这就是wsgiapp本身。
load_middleware()为构建中间件堆栈,这也是wsgiapp获取setting信息的唯一途径。导入settings.py,生成中间件堆栈。
如果看过我之前那篇fastapi源码的,应该对中间件堆栈不陌生。
app入口→中间件堆栈→路由→路由节点→endpoint
所以,wsgiapp就此构建完毕,服务器传入请求至app入口,即可经过中间件到达路由进行分发。
什么时候用懒加载
1.懒加载基本
懒加载——也称为延迟加载,即在需要的时候才加载(效率低,占用内存小)。所谓懒加载,写的是其get方法.
注意:如果是懒加载的话则一定要注意先判断是否已经有了,如果没有那么再去进行实例化
2.使用懒加载的好处:
(1)不必将创建对象的代码全部写在viewDidLoad方法中,代码的可读性更强
(2)每个控件的getter方法中分别负责各自的实例化处理,代码彼此之间的独立性强,松耦合
3.代码示例
1//
2//YYViewController.m
3//-浏览器初步
4//
5//Createdbyappleon-5-.
6//Copyright(c)年itcase.Allrightsreserved.
7//
8
9#import"YYViewController.h"
#definePOTOIMGW
#definePOTOIMGH
#definePOTOIMGX
#definePOTOIMGY
@interfaceYYViewController()
@property(nonatomic,strong)UILabel*firstlab;
@property(nonatomic,strong)UILabel*lastlab;
@property(nonatomic,strong)UIImageView*icon;
@property(nonatomic,strong)UIButton*leftbtn;
@property(nonatomic,strong)UIButton*rightbtn;
@property(nonatomic,strong)NSArray*array;
@property(nonatomic,assign)inti;
-(void)change;
@end
@implementationYYViewController
-(void)viewDidLoad
{
[superviewDidLoad];
[selfchange];
}
-(void)change
{
[self.firstlabsetText:[NSStringstringWithFormat:@"%d/5",self.i+1]];
//先get再set
self.icon.image=[UIImageimageNamed:self.array[self.i][@"name"]];
self.lastlab.text=self.array[self.i][@"desc"];
self.leftbtn.enabled=(self.i!=0);
self.rightbtn.enabled=(self.i!=4);
}
//延迟加载
/**1.的序号标签*/
-(UILabel*)firstlab
{
//判断是否已经有了,若没有,则进行实例化
if(!_firstlab){
_firstlab=[[UILabelalloc]initWithFrame:CGRectMake(,,,)];
[_firstlabsetTextAlignment:NSTextAlignmentCenter];
[self.viewaddSubview:_firstlab];
}
return_firstlab;
}
/**2.控件的延迟加载*/
-(UIImageView*)icon
{
//判断是否已经有了,若没有,则进行实例化
if(!_icon){
_icon=[[UIImageViewalloc]initWithFrame:CGRectMake(POTOIMGX,POTOIMGY,POTOIMGW,POTOIMGH)];
UIImage*image=[UIImageimageNamed:@"biaoqingdi"];
_icon.image=image;
[self.viewaddSubview:_icon];
}
return_icon;
}
/**3.描述控件的延迟加载*/
-(UILabel*)lastlab
{
//判断是否已经有了,若没有,则进行实例化
if(!_lastlab){
_lastlab=[[UILabelalloc]initWithFrame:CGRectMake(,,,)];
[_lastlabsetTextAlignment:NSTextAlignmentCenter];
[self.viewaddSubview:_lastlab];
}
return_lastlab;
}
/**4.左键按钮的延迟加载*/
-(UIButton*)leftbtn
{
//判断是否已经有了,若没有,则进行实例化
if(!_leftbtn){
_leftbtn=[UIButtonbuttonWithType:UIButtonTypeCustom];
_leftbtn.frame=CGRectMake(0,self.view.center.y,,);
[_leftbtnsetBackgroundImage:[UIImageimageNamed:@"left_normal"]forState:UIControlStateNormal];
[_leftbtnsetBackgroundImage:[UIImageimageNamed:@"left_highlighted"]forState:UIControlStateHighlighted];
[self.viewaddSubview:_leftbtn];
[_leftbtnaddTarget:selfaction:@selector(leftclick:)forControlEvents:UIControlEventTouchUpInside];
}
return_leftbtn;
}
/**5.右键按钮的延迟加载*/
-(UIButton*)rightbtn
{
if(!_rightbtn){
_rightbtn=[UIButtonbuttonWithType:UIButtonTypeCustom];
_rightbtn.frame=CGRectMake(POTOIMGX+POTOIMGW+,self.view.center.y,,);
[_rightbtnsetBackgroundImage:[UIImageimageNamed:@"right_normal"]forState:UIControlStateNormal];
[_rightbtnsetBackgroundImage:[UIImageimageNamed:@"right_highlighted"]forState:UIControlStateHighlighted];
[self.viewaddSubview:_rightbtn];
[_rightbtnaddTarget:selfaction:@selector(rightclick:)forControlEvents:UIControlEventTouchUpInside];
}
return_rightbtn;
}
//array的get方法
-(NSArray*)array
{
if(_array==nil){
NSString*path=[[NSBundlemainBundle]pathForResource:@"data"ofType:@"plist"];
_array=[[NSArrayalloc]initWithContentsOfFile:path];
}
return_array;
}
-(void)rightclick:(UIButton*)btn
{
self.i++;
[selfchange];
}
-(void)leftclick:(UIButton*)btn
{
self.i--;
[selfchange];
}
@end
什么是预加载、懒加载先用占位符表示,不要将地址放到src属性中,而是放到其它属性(data-original)中
页面加载完成后,监听窗口滚动,当出现在视窗中时再给它赋予真实的地址,也就是将data-original中的属性拿出来放到src属性中
在滚动页面的过程中,通过给scroll事件绑定lazyload函数,不断的加载出需要的
注意:请对lazyload函数使用防抖与节流,不懂这两的可以自己去查
3.可视区加载
这里也分为两种情况
1、页面滚动的时候计算的位置与滚动的位置
2、通过新的API:IntersectionObserverAPI(可以自动"观察"元素是否可见)
如上,data-属于自定义属性,ele.dataset.可以读取自定义属性集合
img.srcset属性用于设置不同屏幕密度下,image自动加载不同的,比如imgsrc="image-.png"srcset="image-.png2x"/
预加载
提前加载,当用户需要查看时可直接从本地缓存中渲染
加载方式目前主要有两种
待到满足触发条件后,再通过JS渲染
结语:以上就是首席CTO笔记为大家整理的关于Django的懒加载是什么的相关内容解答汇总了,希望对您有所帮助!如果解决了您的问题欢迎分享给更多关注此问题的朋友喔~
Go语言源码阅读分析(3)-- unsafe
Go语言的unsafe包提供了一套打破类型安全限制的操作,但使用时需谨慎,因为它可能导致代码无法移植。包内主要包含unsafe.go文件和一些声明,实际实现和测试用例并未提供。关键内容如下: 1. Pointer类型:可以转换为任何类型的指针,以及Uintptr类型,这种转换允许直接读写内存,风险极高,需谨慎使用。 - 可以将任意类型转换为Pointer类型,但转换后不能长于原类型,且要求内存布局一致。例如,将float转换为uint的函数`Floatbits`。 - Pointer可以转换为uintptr,但这种转换仅用于内存地址的打印,且不能直接从uintptr恢复为Pointer,除非是枚举类型。 2. 偏移指针:用于访问结构体字段或数组元素,需确保指针不会超出原始对象的内存范围。 3. syscall调用:在syscall包中,某些函数需要在同一条语句中进行指针到uintptr的转换,以确保指针指向的对象在调用时仍然有效。 4. reflect包使用:reflect.Value.Pointer和UndafeAddr返回的都是uintptr,应在获取后立即转换为Pointer,避免对象被GC回收。 5. 反射结构体转换:例如StringHeader和SliceHeader的Data字段,仅在指向活动切片或字符串时有效。 总之,unsafe包的使用需遵循特定的规则和限制,不当使用可能导致程序不稳定或移植问题。接下来的计划是研究reflect包。vn.py学习笔记(八)vn.py utility、BarGenerator、ArrayManager源码阅读
在量化投资的探索中,作者对vn.py产生了浓厚的兴趣,并投身于相关学习。目前,作者主要专注于vn.py在A股市场量化策略的学习,面临的主要技术难点包括获取和维持日线数据、实现自动下单交易、开发全市场选股程序、编写选股策略回测程序,以及运用机器学习进行股票趋势预测。作者计划通过阅读vn.py源码,深入了解其架构机制,并通过分享形式记录学习心得,以便更好地理解vn.py。
相关github仓库地址:github.com/PanAndy/quan...
如有收获,请关注公众号以支持作者。同时,作者也收集了一些量化投资和技术相关的视频及书籍资源,欢迎关注公众号亚里随笔获取。
本文将重点探讨vn.py/trader/utility.py中的内容,主要包括工具函数、BarGenerator和ArrayManager。工具函数部分相对容易理解,主要是对通用功能进行封装。BarGenerator是K线合成器,负责根据实时tick数据合成1分钟K线,并进一步合成n分钟K线。ArrayManager是指标计算辅助类,负责维护一定量的历史数据,以供计算sma、ema、atr等常见指标。BarGenerator和ArrayManager是本次学习的重点。
工具函数部分主要提供合约代码转换、路径读取、json文件读写、数值位数设置、日志等功能,主要是对基本功能进行封装,没有复杂的算法。
BarGenerator类用于从tick数据中生成1分钟bar数据,也可以用于从1分钟的bar数据中合成x分钟或x小时的bar。BarGenerator的主要函数包括update_tick、update_bar、update_bar_minute_window、update_bar_hour_window、on_hour_bar和generate。
ArrayManager是一个时间序列容器,用于按时间序列缓存bar数据,提供技术指标的计算。ArrayManager提供的函数分为四类:init函数、update_bar、@property函数和技术指标函数。
Tornado之ioloop源码学习
在闲暇之余,我研究了tornado的源码,并计划以系列文章的形式记录关键部分,旨在总结学习心得并可能对使用该框架的朋友有所帮助。如有疏漏,欢迎私信或评论指正。
在研究开源项目时,我通常选择原始版本的tornadoweb/tornado,因为我认为其核心功能通常在1.0.0版本就已经完备,后续的改进主要集中在细节,而非重大功能。代码风格的统一性可能会因不同开发者提交的代码而有所差异。
在阅读之前,我建议您对Linux的IO模型有所了解,特别是epoll和kqueue(在Mac或BSD系统中)的概念。Python 2.6及以上版本的select库提供了相关实现,但2.6以下版本则需要依赖tornado对底层epoll的封装。以下代码正是处理这个选择过程的。
接下来,让我们深入探讨tornado的内部。首先,我们关注的是底层的 epoll 实现,如 GitHub 上的代码。它提供了常规的epoll功能,熟悉该技术的开发者一眼就能看懂。
然后是 IOLoop 类,我们从头开始分析。其中定义了 epoll 中的关键事件,如 _EPOLLIN 和 _EPOLLOUT,分别表示文件描述符的读写就绪状态。
在代码中,_set_close_exec 方法的作用是解决子进程 fork 后可能遇到的问题。当子进程仅被 fork 并执行 exec 时,原有的文件描述符可能会消失,这个方法确保在 exec 时关闭这些描述符。
r, w = os.pipe() 则创建了一个管道,用于高效地中断 IOLoop 循环。当管道另一端写入数据时,会阻塞 poll() 方法,从而停止循环。
此外,IOLoop 通过 signal 模块监控 block 时间,当超过设定时间,将执行预先定义的 handler。信号 SIGALRM 和 ITIMER_REAL 通常一起使用。
至关重要的 start 方法下,有几个辅助方法。_callbacks 存储了将在下一次 IOLoop 循环前调用的函数,保证跨线程安全。相比之下,_timeouts 保存了执行函数和截止时间的对应关系,允许延迟执行。
关于 poll_timeout 的设置,它决定了 IOLoop 等待就绪事件的时间。默认值为 0.2 秒,如果存在可以执行的回调,会调整为尽快执行。最后,IOLoop 通过 poll 函数获取就绪事件,使用 signal.ITIMER_REAL 进行计时,处理后利用 pop 方法而非遍历,避免映射关系在处理过程中变化。
以上就是对 IOLoop 的基本介绍,期待你的反馈和指正。
2024-11-30 07:33
2024-11-30 07:16
2024-11-30 06:58
2024-11-30 06:07
2024-11-30 05:41
2024-11-30 05:37