Category Archives: Hello World

Hello World

pandas日期的高效处理方法

2023 年 12 月 26 日 – 上午 7:45

每次碰到dataframe里有datetime字段，都会感觉很麻烦，明明知道pandas里有很多批量处理的方法，但一个datetime改字符串日期，之前试过过很多写法，都不成功，又不甘心用低效的apply，于是动个小聪明，直接前置到提取数据的sql里：SUBSTR(created,1,10) day ^_^
今天又碰到这类问题，数据来源十几张表，而且是之前现成的公共模块，不好随便改sql，无奈找pandas里的处理方法，这次居然轻而易举找到了：
df['day'] = df['created'].dt.strftime(‘%Y-%m-%d’)
嗯，其实就这么简简单单一行代码~~继而好奇进一步研究了这里面的“dt”对象，除了搭配strftime()做日期格式化，还可以直接dt.year/dt.month/dt/time/dt.quarter/dt.weekday，还有dt.dayofyear/dt.weekofyear，哈哈，没错，可以理解成里面藏了一个map
除了这些，还可以类似这么用：(df['日期1'] – df['日期2']).dt.days、(df['日期1'] – df['日期2']).dt.total_seconds()

Tags , | Permalink | Comment (0)
Hello World

dataframe拆字段

2023 年 11 月 02 日 – 上午 10:05

比如，数据源某字段格式：“13/34”，来表示门店每日的新老用户数，现在要把它拆成两个字段，以便下一步分析使用。当然，我们首先肯定想到可以apply，可是如果数据量太大，apply就会变得很慢。那么，有没有更快的办法？
当然有了，毕竟pandas总不会让我们失望
df['new'], df['old'] = df['user_count'].str.split(‘/’, 1).str
简简单单一行代码就完成了

———
over, 参考：https://zhuanlan.zhihu.com/p/343895339

Tags , | Permalink | Comment (0)
Hello World

pandas之pivot_table的使用

2023 年 10 月 27 日 – 上午 7:20

pivot_table是将多行数据转成多列的一个函数，作用类似exce的透视表，这里咱们先看一下它的实际处理效果：

再看代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

#构建测试数据
df = pd.DataFrame({
	'品类': ['苹果', '橘子', '香蕉', '橘子', '香蕉', '橘子'],
	'日期': ['2023-10-21', '2023-10-21', '2023-10-21', '2023-10-22', '2023-10-23','2023-10-23'],
	'销量': [13, 24, 25, 27, 19, 21]
	},
	columns=['品类', '日期', '销量']
)
print(df)
#日期列转行 index 行索引，columns 要转为列名的行，values 要转为列值的行
df2 = pd.pivot_table(df, index=['品类'], columns=['日期'], values=['销量'])
df2.fillna(0, inplace=True)
print(df2)

———-
over，转载请注明出处：http://www.jiangkl.com/2023/10/pivot_table

Tags , | Permalink | Comment (0)
Hello World

macOS to_pickle的一个小坑

2023 年 05 月 29 日 – 上午 9:49

本地数据分析，mysql提取初始数据后，中间数据准备用pkl暂存，但是实际执行，to_pickle这行报错了：
OSError: [Errno 22] Invalid argument
简单搜了一下解决方案，定位在”pkl对象太大，大于2G，macos无法直接dump”，解决方案是分批存：

不过我没按上面这个方法做，而是用了更偷懒的分段方法：分成两个dkl保存~~(*^▽^*)

Permalink | Comment (0)
Hello World

Label对Drawcall的影响测试

2023 年 04 月 02 日 – 上午 7:41

众所周知，drawcall的数量是影响CocosCreator流畅度的一个重要指标，本文主要测试Label与Sprite混排时对性能的影响，主要有下面几个对照量：
1. 运行环境，共三种：
    a. mac端chrome浏览器（开启开发者工具、尺寸模拟iphon12pro）
    b. iphone（8plus）自带浏览器
    c. android（其实是鸿蒙、麒麟820/6G运存）自带浏览器
2. Label属性CacheMode，这里节选一下官方文档：
    a. None: 默认值，Label 中的整段文本将生成一张位图
    b. BitMap: 选择后，Label 中的整段文本仍将生成一张位图，但是会尽量参与 动态合图。只要满足动态合图的要求，就会和动态合图中的其它 Sprite 或者 Label 合并 Draw Call。由于动态合图会占用更多内存，该模式只能用于文本不常更新的 Label
    c. Char: 原理类似 BMFont，Label 将以“字”为单位将文本缓存到全局共享的位图中，相同字体样式和字号的每个字符将在全局共享一份缓存。能支持文本的频繁修改，对性能和内存最友好……不能参与动态合图（同样启用 CHAR 模式的多个 Label 在渲染顺序不被打断的情况下仍然能合并 Draw Call）
3. 节点形态：每一个精灵节点下，加一个Label子节点;精灵节点简单转动或摆动；Label仅显示数字，使用系统字体；测试过程共分三种情况：50/200/1000个节点
4. Label节点除了会修改CacheMode，还会尝试两种情况：不修改文案内容、每秒修改一次文案内容
基本的测试要素就是上面这些，下面来看测试结果

简单总结几个结论：
1. 就像文档里说的，对于固定内容的Label，BitMap确实对性能有巨大帮助，可以通过合批最大程度减少Drawcall
2. 对于Label和Sprite混排的情况，文本如果还要频繁更新，性能必然会受影响，如果预期这类节点数量很多，一定不能这么做
3. 虽然测试用的chrome浏览器已经开启了硬件加速，但或许是对m1mac的适配不好，这次测试chrome浏览器的表现完败，甚至不如六年前的iphone手机。（试了一下mac自带的safar浏览器，表现和iphone手机浏览器差不多）
那么，针对上面提到的第二条，如果确实需要大量、频繁更新的文本，应该怎么办？看文档大概有下面两种解决方案：
1. 使用艺术字图集代替系统字体
2. 将Label节点提出来，不要和Sprite混编
后续有时间试试这两种方案的效果 o(*￣︶￣*)o
————
转载请注明出处：http://www.jiangkl.com/2023/04/cocos_label_drawcall
————
补充：
继续上面的话题，按照第2个解决方案对项目做了“优化”，也就是将所有的Label提取出来，单独放在一个节点了，和Sprite区隔开，测试结果：
1000个节点的情况下，三个端都能轻松运行，FPS 60，Drawcall 5，成功将1000个Label合批到一个Drawcall！

Tags , | Permalink | Comment (0)

« 上一页 — 下一页 »

« 上一页 — 下一页 »