r**o
发帖数: 10 | 1 【 以下文字转载自 JobHunting 讨论区 】
发信人: rewo (rewo), 信区: JobHunting
标 题: 一道面试题没回答好，学CS的看看
发信站: BBS 未名空间站 (Thu Apr 12 10:57:33 2007)
如果发现程序（in Java )运行得很慢，troubleshoot一下软件中可能存在的问题？ |
m******t
发帖数: 2416 | 2 I'd start with reviewing the design, then reviewing the code, then if
nothing looks wrong on the surface, get your hands dirty and plug in some
profiler. |
g*****g
发帖数: 34805 | 3 The 80-20 law is always the key, log timestamp to figure out what's
realy slow in certain operation is sufficient for most projects.
If the sluggish is system wide though, I'll start with design review.
【在 m******t 的大作中提到】
: I'd start with reviewing the design, then reviewing the code, then if
: nothing looks wrong on the surface, get your hands dirty and plug in some
: profiler.
|
j******o
发帖数: 82 | 4 I think the interviewer is trying to ask for
specific areas where a program would run slow
in Java that would otherwise run fine if written
in C++. :-)
【在 r**o 的大作中提到】
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: rewo (rewo), 信区: JobHunting
: 标 题: 一道面试题没回答好，学CS的看看
: 发信站: BBS 未名空间站 (Thu Apr 12 10:57:33 2007)
: 如果发现程序（in Java )运行得很慢，troubleshoot一下软件中可能存在的问题？
|
c*m
发帖数: 836 | 5 Then what to do? Re-write the program in C++ using the same design and see
if it's faster?
Seriously, just to say a program 'run slow' is too broad a statement. I
would first ask the symptoms, CPU being pegged? High I/O activity? Normal
CPU usage and disk IO but slow response time? etc.
Regardless with the symptoms, I would always start with getting a thread
dump once the system starts 'running slow'. It's quick and dirty, and gives
a snap shot of the activities going on in the VM. Take a series
【在 j******o 的大作中提到】
: I think the interviewer is trying to ask for
: specific areas where a program would run slow
: in Java that would otherwise run fine if written
: in C++. :-)
|
r**o
发帖数: 10 | 6 我当时只从code方面去考虑这个问题了，所以没答好
【在 m******t 的大作中提到】
: I'd start with reviewing the design, then reviewing the code, then if
: nothing looks wrong on the surface, get your hands dirty and plug in some
: profiler.
|
r**o
发帖数: 10 | 7 thanks, what's the best way to log timestamp? add several line of codes or
use debug tools?
【在 g*****g 的大作中提到】
: The 80-20 law is always the key, log timestamp to figure out what's
: realy slow in certain operation is sufficient for most projects.
: If the sluggish is system wide though, I'll start with design review.
|
r**o
发帖数: 10 | 8 都是高手呀，又长了见识
gives
dumps
,
【在 c*m 的大作中提到】
: Then what to do? Re-write the program in C++ using the same design and see
: if it's faster?
: Seriously, just to say a program 'run slow' is too broad a statement. I
: would first ask the symptoms, CPU being pegged? High I/O activity? Normal
: CPU usage and disk IO but slow response time? etc.
: Regardless with the symptoms, I would always start with getting a thread
: dump once the system starts 'running slow'. It's quick and dirty, and gives
: a snap shot of the activities going on in the VM. Take a series
|
g*****g
发帖数: 34805 | 9 Simple log4j is good enough, you can turn if on and off without
rewriting code, if things really get ugly though, find a profiler.
【在 r**o 的大作中提到】
: thanks, what's the best way to log timestamp? add several line of codes or
: use debug tools?
|
A**o
发帖数: 1550 | 10 就是一道工作经验题，有没有debug经验这么一问大概就出来。
【在 r**o 的大作中提到】
: 都是高手呀，又长了见识
:
: gives
: dumps
: ,
|
g******u
发帖数: 153 | 11 同意
没有标准答案，看你解决问题的能力
最好的回答是，现概要地说一下可能是什么问题，怎么查。怎么narrow down scope,
到底是前台慢，java server慢还是数据库慢。
接着举例说明自己有类似的debug经验。要对你碰到的问题进行描述，说说你当时具体
怎么解决的。其实这些例子应该在面试前都准备好的，随时拿来用。
【在 A**o 的大作中提到】
: 就是一道工作经验题，有没有debug经验这么一问大概就出来。
|
r**o
发帖数: 10 | 12 我上来就卡在了 “现概要地说一下可能是什么问题”， 头一次被问道这个问题，没有
准备
【在 g******u 的大作中提到】
: 同意
: 没有标准答案，看你解决问题的能力
: 最好的回答是，现概要地说一下可能是什么问题，怎么查。怎么narrow down scope,
: 到底是前台慢，java server慢还是数据库慢。
: 接着举例说明自己有类似的debug经验。要对你碰到的问题进行描述，说说你当时具体
: 怎么解决的。其实这些例子应该在面试前都准备好的，随时拿来用。
|
c*****t
发帖数: 1879 | 13 其实这个东西比较通用，并不局限在 Java。答案无非就是
1. I/O (including Network)
2. Backend services (database etc)
3. Algorithm
4. Coding
5. Memory constraint or other hardware limits
在 profiling 的一点就是要有针对性的修改。必须先发现哪出了问题
再修改。上来就 code review 其实没用。一个很少用到的 function
即使稍微慢点，并不重要。一个经常用到的 function 即使已经比较
快了，可能还要继续 optimize 。所以第一步是先考察是否慢，慢在
哪里。以后才是分析怎么解决。而解决办法经常会改变 algorithm，
甚至整个 design 。
有这个思想以后，写程序就自然而然注意到什么时候图编程速度，什么
时候稍微注意一下用的 algorithm 等。
【在 r**o 的大作中提到】
: 我上来就卡在了 “现概要地说一下可能是什么问题”， 头一次被问道这个问题，没有
: 准备
|
r**o
发帖数: 10 | 14 谢谢！！
【在 c*****t 的大作中提到】
: 其实这个东西比较通用，并不局限在 Java。答案无非就是
: 1. I/O (including Network)
: 2. Backend services (database etc)
: 3. Algorithm
: 4. Coding
: 5. Memory constraint or other hardware limits
: 在 profiling 的一点就是要有针对性的修改。必须先发现哪出了问题
: 再修改。上来就 code review 其实没用。一个很少用到的 function
: 即使稍微慢点，并不重要。一个经常用到的 function 即使已经比较
: 快了，可能还要继续 optimize 。所以第一步是先考察是否慢，慢在
|
