V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  xingheng  ›  全部回复第 15 页 / 共 16 页
回复总数  301
1 ... 7  8  9  10  11  12  13  14  15  16  
2019-11-07 17:08:03 +08:00
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@kera0a 对方明确说明了调用方数量确实会有很大,我猜测还是 NSString 作为 key 的内存占用量会很大。

也不排除因为他们的 app 在正常运行的时候其他需求上已经占用大量内存了,只是针对或者设计了这样一个问题来优化这个统计结果。
2019-11-07 17:03:04 +08:00
回复了 xingheng 创建的主题 Objective-C iOS/Objective-C - NSMutableDictionary 撑爆了内存?
@w99wen 确实想过串行的方法,把初始化和 dict 的操作都挪到串行队列里面去。主要问题还是内存,以我的理解,NSMutableDictionary 在 setValue:forKey:的时候确实会对 NSString \*key 进行 copy,但是这个 copy 不会产生新的内存分配(假定是 inmutable string ),只是把原有的 imutable string's retain count 加 1。上面说 NSMutableDictionary 的撑爆内存其实是指 NSMutableDictionary 持有的 NSString 把内存撑爆了。

这个理解有错误吗?请指正。

写 io 的话也想过,一旦 NSMutableDictionary 的数量级到了某个设定量就写文件,这样的话就还需要再次汇总结果了,可能不符合对方的预期。

这个问题来自蚂蚁金服的面试官。
2019-11-07 13:30:50 +08:00
回复了 daijinming 创建的主题 程序员 dotnet 开发 API 的时候使用 asyn 、await 有什么优势吗
@crclz 有理。那我们再往下(main thread)追溯,(我没有写过 c#服务端,从其他语言推断的),main thread 或者说函数入口一定是 sync,每一个从 port 过来的请求一定是在 c#服务端对应一个 working thread 的,高效管理是语言级的特性,但是 working thread 的数量一定是不会减少的,working thread 之间(对外)也没有依赖关系,所以并发量还是没有增大。

我上面的蛋炒饭(async)假定确实很 critical,全程只有一个 async task 的需求是非常少见的,async 在这种情况下应该是没有什么好处的,高效管理只是说损耗很小,但不是没有。

async 在设计层面上是成功的,也推荐使用。在 API 设计层面上我觉得只是相对提高了响应请求处理的单位时间,勉强上可以说是间接地提高了并发量。

请指正。
2019-11-07 13:01:53 +08:00
回复了 smyle 创建的主题 Python Python 新手,怎么读 Python 源码?一个项目里的封装、库太多了
pydoc -k
2019-11-07 13:00:03 +08:00
回复了 hjq98765 创建的主题 Python Python 的 json 包好像有个小 bug?
Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 29 2018, 20:59:26)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin

>>> json.dumps({'y': 17318, 'info_total_periods': 12})
'{"y": 17318, "info_total_periods": 12}'
>>> json.dumps(cc)
'{"y": 17318, "info_total_periods": 12}'
>>>

没有重现
2019-11-07 11:12:51 +08:00
回复了 daijinming 创建的主题 程序员 dotnet 开发 API 的时候使用 asyn 、await 有什么优势吗
@xuanbg 这个🌰好。但是如果有客人(request)就点了一个蛋炒饭(async),这样的话我觉得 sync 版的蛋烧饭会比 async 版的蛋炒饭更快,因为没有切换线程的损耗了。

关于楼上提到的并发量提高的问题我有些质疑,一个 request 在发起到完成之前,这个 working thread 应该是一直存在的,并不会因为 async 的使用导致 working thread dispose 或者 reuse 的情况。

我的理解对吗?
2019-11-07 10:48:42 +08:00
回复了 curiouscat 创建的主题 程序员 开源我的一个邪恶项目
Talk is cheap, show me the code.
2019-10-30 23:05:19 +08:00
回复了 dackh 创建的主题 程序员 写脚本哪家强
提到脚本居然不提 bash,那还是脚本嘛!
2019-10-22 14:32:08 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@baiyi

{"data":null}这种数据在前后端都有框架可以实现过滤;
现在主流的 iOS 数据序列化框架都可以区分{}和[],你是不是被你们 iOS 客户端开发忽悠了
2019-10-22 14:26:40 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@Narcissu5 如果客户端要实现 code=9001 的时候立刻弹出登录页重新登录呢?这种逻辑绝对不止 1%
2019-10-22 14:20:48 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@helone 客户端有时候需要基于后台不同的 code 来实现不同的页面跳转等等特定需求
kon9chunkit 这是个什么破名字,私人汇总玩一下就可以了。高端玩法儿都是单独在 github 上创建 organization,然后托管,这样才上档次!
2019-10-22 13:59:00 +08:00
回复了 b00tyhunt3r 创建的主题 程序员 OSX 怎么让 terminal 命令行支持自己写的程序
nginx 和 brew 这类命令可以直接在你的 terminal 里面用是因为你当前 shell session 的环境变量 PATH 里面包含了他们的所在路径,用`where brew`可以找到对应执行入口的路径。

vim $(where brew),查看 brew 的执行入口文件是什么样的:
#!/bin/bash
set +o posix
....

从这里开始 shell 会解释执行这个 bash 脚本文件....你可以把自己写的脚本文件放到 PATH 之中的任一路径中,然后使用脚本文件名就可以被 shell 发现。

当然还有其他方法,比如 alias,shell/bash function,都可以满足你的这类需求。
2019-04-28 17:32:29 +08:00
回复了 moyupoi 创建的主题 程序员 百度字节两大毒瘤互相伤害
百度搜索的结果也能用?头条也真够不挑的了,rua ji !
2019-04-28 14:32:11 +08:00
回复了 luanguang 创建的主题 程序员 贩卖焦虑,然后推荐网课,这套路越来越普遍了
说到网课,现在#python 的教学类课应该是推得最多吧
2019-04-21 21:11:48 +08:00
回复了 bookit 创建的主题 macOS macOS 10.14.4 真是 bug 一堆
只看标题差点把我的手缩回来了,还好不用 PD。。。
用 awk 和 shell 可以实现:

先分片,找到所有期望的元素:
awk -F '[[:space:]]+|:|,|=' '{ print $1" "$4" "$10 }'

然后用 rev 实现反转:
awk '{ system("echo $(echo "$1" | rev) " ); }'

拼起来:
awk -F '[[:space:]]+|:|,|=' '{ system("echo $(echo "$1" | rev) " $4" "$10); }'

看了一下我的环境,rev 是 BSD 的命令,Linux 和 macOS 都内置
@buhi 头一次看到有人讽刺 shell 是一坨屎的
1 ... 7  8  9  10  11  12  13  14  15  16  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2229 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 43ms · UTC 01:37 · PVG 09:37 · LAX 17:37 · JFK 20:37
Developed with CodeLauncher
♥ Do have faith in what you're doing.